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ABSTRACT 


This thesis presents the detailed design and implementation 
of the kernel of a real-time, distributed operating system 
for a microcomputer based multiprocessor system. 

Process oriented structure, segmented address spaces and 
a synchronization mechanism based on eventcounts and sequencers 
comprise the central concepts around which this operating 
system is built. 

The operating system is hierarchically structured, layered 
in three loop free levels of abstraction and fundamentally 
configuration independent. This design permits the logical 
distribution of the kernel functions in the address space of 
each process and the physical distribution of system code and 
data among the microcomputers. This physical distribution in 
turn, in a multimicroprocessor configuration will help to 
Minimize system bus contention. 

The system particularly supports applications where 
processing iS partitioned into a set of multiple interacting 
asynchronous processes. One such application is that of 
Smart sensor image processing for which this system has been 
specifically developed. The implementation was developed for 
the INTEL 86/12A single-board computer using the 8086 


processor chip. 
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ft.) feRODUCTION 


The topic of this thesis is the detailed design and 
implementation of the kernel of a real-time, distributed 


operating system for a multiple microcomputer system. 


A. MOTIVATION 

In the Electro-Optics Signal Processing Laboratory at 
the Naval Postgraduate School, research is currently being 
conducted in the area of "Smart Sensor image processing". 
Specifically image processing for long distance missile 
detection, high-altitude surveillance and target acquisition 
for tactical missiles is the topic presently being investigated. 

The smart sensor platform will require on-board data 
processing of large quantities of collected image data. 

To provide the required “computing power" for a high 
input data rate which processes that data in "real time", a 
multiple microcomputer system is being developed capable of 
performing concurrent asynchronous computations. 

A large image processing program can be partitioned into 
small interactive parts. These will be dynamically assigned 
to the microcomputers available in the system for concurrent 
"parallel" and "pipeline" processing. 

If properly designed and executed, the concurrent computing 
will both increase the throughput and decrease the execution 
time. 


16 





To facilitate the dynamic assignment of the partitioned 
processes of a program for effective computations by a 
multiple microcomputer system, a real-time distributed 
operating system is needed and this is the topic of the 


present thesis. 


Eee VLISCUSSION 

The processing power of microprocessors is increasing. 

If this power can be effectively coordinated by an opera- 
ting system, it would provide a more affordable and powerful 
weoauct. 

The application of contemporary microprocessor technology 
to the design of large-scale multiple processor systems offers 
many potential benefits. For example, the "cost" of high- 
power computer systems could be reduced drastically, and 
"fault tolerance" in critical real-time systems could be 
improved. Designing such systems presents many formidable 
problems that have not been solved by the single processor 
systems available today. 

The multi-microprocessor systems in use today suffer 
performance degradation as more processors are added to the 
system. Sophisticated interconnections among processors and 
memories are needed to reduce this problem. 

Despite the rapidly expanding capabilities of modern 
microcomputer systems, they still are limited bv the 


relatively slow execution speeds of their microprocessors, 
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for many real-time military applications. These systems 
generally do not provide the power and flexibility required 
to address complex and demanding applications. One such 
area is that of "real-time digital image processing". This 
is a particularly demanding application area, characterized 
by the requirement to apply significant "processing power" 
to a high input data rate. 

An answer to the inadequacies of the single microcomputer 
is to provide for miltiple microcomputer systems. Such 
systems could provide the processing power necessary to handle 
those applications, which are presently addressed by mini- 
computers and mainframe systems. However, most of today's 
microcomputer operating systems deal only witha single 
processor and cannot adequately manage multiple processors. 

The integration of large numbers of relatively inexpensive 
Microcomputers into powerful computer systems has been the 
subject of intensive research in universities and industry 
for several years. 

The primary thrust of this thesis is towards a general 
architecture which can be applied to hardware systems, that 
are commercially available today (this project is currently 
using the INTEL general purpose 16-bit 8086 Microprocessor), 
with some custom-developed hardware for intercommunication 


network and control. 
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C. BACKGROUND 

The system software design uses the MULTICS [9] concepts 
of segmentation and "per process stack", in conjunction with 
Reed's [15] design of virtual processors, and Reed and 
Kanodia [10] eventcount synchronization mechanism. 

The basic microcomputer operating system design was 
developed by O'Connell and Richardson [7] and is based on the 
structure of a hierarchical kernel, where security kernel tech- 
nology was used. O'Connell and Richardson first developed a 
flexible operating system design that is fundamentally 
configuration independent and adaptable to a spectrum of 
systems. 

J. Wasson [8], in his thesis defined the detailed kernel 
design of one member of the above family, a modified real-time 
subset, tailored to "real-time image processing" and applied to 
the INTEL 16-bit general purpose 8086 Microprocessor. 

The objective of this thesis is to complete the above 
design and also to write a detailed code implementation. 

The result is a layered loop free operating system which 
is both small and easy to analyze. 

The system supports miltiple asynchronous processes, using 
the concept of "two-level traffic control", to accomplish 
“processor multiplexing" amongst a greater number of 
eligible processes. This dual-level "processor multiplexing" 


design allows the system to treat the two primary scheduling 


ing 





decisions, viz., the scheduling of processes and the manage- 
ment of processors, at two separate levels of abstraction. 

The kernel comprises a complete, albeit primitive, 
operating system providing support for a large number of 
asynchronous processes. 

The kernel manages all physical processor resources, and 
provides scheduling and interprocess communication and 
synchronization and also provides the user with an execution 
environment which is relatively free from concern about the 
underlying hardware configuration. The system is capable of 
performing in a real-time environment through the use of 
“preemptive scheduling", to ensure expeditious handling of 


time-critical processing requirements. 


Peo lh RUCTURE OF THE THESIS 

Chapter I presented a general discussion and the thesis' 
Paeeground. 

Chapter II, describes the overall design philosophy of 
the operating system, its functional requirements, how 
multiple processes communicate and synchronize their tasks, 
and finally how these processes are multiplexed on a smaller 
set of processors. 

Chapter III describes the hardware architecture of the 
multiprocessor system. The INTEL 8086 Microprocessor was 
chosen for this implementation. 


Chapter IV describes the details of the system design. 
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Chapter V presents conclusions and observations that 
resulted from this effort and also suggestions for further 


research. 
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IT. FUNDAMENTAL DESIGN CONCEPTS 


DESIGN PHILOSOPHY 

The kernel primitives which provide multiprogramming 
processor management and process management, form one member 
of the family of operating systems designed by O'Connell and 
Richardson [7]. This member is a modified real-time subset. 
The modification consists of the inclusion of a more general 
synchronization mechanism, eventcounts and sequencers describ- 
ed by Reed and Kanodia [10], which replace the more tradi- 
tional Signal/Wait and Block/Wakeup used in the original 
design. 

Before presenting the details of this operating system, 
the high level design and the detailed "working implementa- 
tion" of the system, it is useful to investigate the general 
design methodology applied to the development of this 
operating system. 

Multiple processor systems are intrinsically more complex 
than the familiar uniprocessor. Their complexity has proven 
to be the major barrier to realize the full potential of 
the inherent parallelism available in such a system. 

One of the most important components of any computer 
system is the operating system. The operating system manages 
the system's resources. Thus system performance is critically 


dependent upon its effectiveness. 
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We can say that basically two issues confront the operat- 
ing system designer. First, he must provide system functions 
that support the services requested by the user. These 
functional requirements affect the logical design of the 
system. Second, he must address issues of cost and 
performance. Cost and other management considerations will 
not be addressed here. Performance issues concern the 
management of physical resources and has to do with the 
computational speed, and also system attributes such as the 
ease of programming, efficiency, correct operation, etc. 

There is a considerable amount of literature devoted to 
the development of the functional design of operating systems. 
Dijkstra [12] has described atechnique for reducing the 
complexity of the design by allocating operating system 
activities to a number of cooperating processes. Process 
Structure is simplified in turn, by defining its functions 
in levels of increasing abstraction, and by applying the 
principles of structured programming. 

Madnick and Donovan [13] have described an operating 
system as a hierarchical extended machine. Program modules 
are added to the system to provide many extended instructions, 
in addition to the hardware instructions available on the 
bare machine. In complex systems, one extended machine may 
be constructed upon another to form a system composed of 
levels of abstraction (virtualmachines). Figure 1 from 


Reference [13], presents the general idea of that hierarchical 
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extended machine and levels of abstraction built on the 
bare machine. 

Saltzer [14] and Reed [10, 15] have discussed the advan- 
tages of resource virtualization and have described useful 
interprocess communication and synchronization mechanisms. 
The general design strategies presented in this thesis 
will aid the operating system designer in developing system 
functions in a clean, logical, verifiable design. 

Finally, adequate performance can only be assured 1f 
the behavior of the system is well understood and this in 
turn imposes a strict requirement for simplicity. 

In this design, the requirement for simplicity is 
satisfied by utilizing a model based on the notion of 
multiple asychronous processes with segmented address spaces. 
This 1s the central unifying concept which provides a 
straightforward view of both static and dynamic system 
behavior [4]. The principles of structured system design 
are also applied to logically organize the operating system 
into a hierarchically structured set of easily understood 
modules whose interactions are clearly specified and strictly 
enforced. 

The result is a modular, layered operating system which 
makes it eaSier to ensure correct operation and provides 
better opportunity for improving performance through tuning. 


Finally, because the system is small, less memory is used for 
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Operating system code and less processor time is spent in 
its execution. 

The operating system design is logically organized into 
a hierarchy that separates the user application processes 
from the kernel. This modular, layered design lends itself 
to "dynamic reconfiguration" where processes can be relocated 
among physical processors [19]. Additionally, the system 
initialization technique proposed by Anderson [19] provides a 
basis for an automatic recovery mechanism that will initialize 
the system on a new physical configuration after the detect- 


ion of faulty system components. 


B. FUNCTIONAL REQUIREMENTS 

The functional requirements defined below support the 
Specific design goals of the system and provide features 
desirable in any operating system, such as: a logical struct- 
ure, fault tolerance and efficiency of operation. Functional 
requirements define services that must be provided to support 
the user's environment. 

1. Process structure 

By dividing a job into asynchronous parts and execut- 

ing these parts as separate entities, significant benefits 
can be realized. Within a single processor system the 
partitioning into asynchronous parts provides the "only" 
design simplicity. But in a multi-processor system, the 


partitioning into asynchronous parts is essential, if the 
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"parallel and pipeline processing" potential of the system 
is going to be used. 
2. Definition of a process. Process organization 
The abstract idea of a process has been defined 
in several ways. A simple one offered by J. Saltzer is 


the following: 


"a process 1S a program in execution on a 
processor." [14] 


A process is the sequence of actions taken by some 
processor. In other words, it can be viewed as the past, 
present ad future "history" of the state of the processor. 
The notion of a process provides a complete description of 
all instructions executed and all memory locations referenced 
during the performance of a task. 

Considering the above definition, it becomes clear 
that there are two elements which together completely 
characterize and define a given process. These are the 
process! "address space" and the "execution point." 

The address space is the set of memory locations that 
could be accessed during process execution. The execution 
point is the state of the processor at a given instant 
during process execution (and is characterized by the contents 
of certain processor registers). 

In the abstract view, an address space is defined by 
a collection of discrete points, each representing a memory 


word. The process is described by the path traced through 
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this address space from process creation to its destruction. 
In Figure 2 the main path, shown by a heavy black line, 
traces the process execution point as it moves from one 
instruction (i.e., memory word) to another during process 
execution. The branches from this execution point path 
represent data references. 

The concept of a process has proven to be a funda- 
mental and powerful one in the organization of computer 
systems. By designing a system as a collection of coopera- 
ting processes, system complexity can be greatly reduced. 
This is because the asynchronous nature of the system can be 
structured logically by representing each independent 
sequential task as a process and by providing interprocess 
synchronization and communication mechanisms to prevent 


"race" and "deadlock" situations during process interactions. 
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Several advantages result from using this process 
Oriented design. As a tool for dealing with the asynchronous 
nature of system operation, processes provide a simple, 
logical, high-level structure for the design. Since each 
process is confined to a specific address space, tasks are 
isolated from one another and system fault tolerance can be 
improved. 

Each process is assigned a unique identifier and is 
an explicit entity that requires management. 

In a "distributed" operating system, those portions 
of the operating system that are logically part of the 
sequential flow of control (viz., locus of execution) are 
within the address space of each user process. This is made 
possible by dividing the operating system into procedures 
that are called like any other application procedure. 

It should be noted that in a distributed operating 
system there is no "master" assigning processes to processors. 
Rather, each running process "gives up" its processor to the 
next process that is ready to run. 

The address space of a process we can say, provides 
a container for the process which isolates it from any 
other process. This eliminates the possibility of inter- 
process interference simply because processes are unable 


to “escape" the confines of their defined address spaces. 
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However, this is rather restrictive in that processes 
which are totally ignorant of each other have no hope of 
co-operating towards the accomplishment of some greater goal. 
In order to mediate this constraint, one desires to allow 
some restricted (controlled) form of address space overlap, 
(viz., Sharing), such that co-operation is allowed while 
still retaining the benefits of protection offered by 
isolation. Sharing requires some way of distinguishing the 
Shared portions of the address space. This is greatly 
facilitated by introducing the notion of memory segmentation. 

Finally, to distinguish between a process and a 
processor (physical or virtual), we can say that the major 
difference is that a processor is an "actor", while a process 
is a sequence of "actions" taken by that actor. A process 
results from the actions of a processor. 

3. Virtual Memory and Segmentation 

In many memory handling schemes, processes cannot run 
unless the entire address space is loaded in primary memory. 
This may require a large main memory or it may restrict the 
Size of the address space. An alternative plan requires an 
operating system which manages primary and secondary memory 
to create the "illusion" of a memory which is larger than 
system's primary memory. Since the larger memory is only 
an illusion,it is often called "virtual" storage. 

Virtual memory is used to implement the concept of a 
“per process" address space. In Multics [16] each process is 
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provided with its own virtual memory for an address space. 
These virtual memories are completely independent of one 
another. 

A virtual memory (the address space of a process) is 
composed of a set of segments. A segment is a logical col- 
lection of information (e.g., procedure, data structure, 
file, etc.) and is the basic logical object of this design. 
Segments are distinct "variable size" memory objects contain- 
ing a sequence of words with conventional linear addresses. 
Associated with a segment is a set of logical attributes 
used to uniquely identify the segment and to control access 
emt. 

In specifying the set of segments that comprise a 
Virtual memory, one may include segments that are also 
part of "other" virtual memories as well. So in addition, 
segmentation supports “information sharing" since a segment 
may belong to more than one address space. Segmentation 
provides a means of associating logical attributes and labels 
with each segment, such as, access class, domain, etc. Thus, 
segments can be shared in a controlled manner to provide for 
inter-process communication and synchronization. 

By using segmentation to provide a virtual memory 
environment, the user is presented with a configuration 
independent system in that he "sees" a process address space 
that he can consider "his own" and is not dependent on the 


assignment of physical addresses. 


orl 


a. Addressing in a Segmented System 

Addressing in a segmented memory system is 
"two-dimensional", That is, a complete address consists of 
two parts. The first is the "segment number", This identi- 
fies the particular segment of interest. One attribute of 
the segment is the physical address of the segment's base. 
Thus the segment can be located anywhere in physical memory 
Just by changing this base address. The second dimension 
of the address is an "offset" relative to the segment's base 
(the beginning of the segment). This serves to access 
Specific locations within the segment. 

This two-dimensional addressing "frees" informa- 
tion from dependence on a particular memory location by 
making it arbitrarily "relocatable", 

Figure 3 illustrates the two-dimensional nature 
of the segment address. The descriptor segment provides a 
list of descriptors for all segments in a process address 
Space. As previously mentioned, one attribute of the segment, 
given by the segment descriptor, is the "physical" address 
of the segment's base. Then the second dimension needed to 
access a specific memory word within this segment is given 
as an "offset" from the segment's base, (SEG #n, OFFSET), e.g., 
( lst dimension, 2nd dimension). So, in segmented addressing, 
each address is characterized by an ordered pair of numbers 


(lst dimension, 2nd dimension). 
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Because of the similarities in address mapping 
hardware, very often the distinction between paging and 
segmentation is confused. To distinguish between page and 
segment, we emphasize the conceptual differences here. The 
major difference is that a segment is a "logical" unit of 
information "visible" to the user's program and is of 
"arbitrary size", A page 1s a "physical" unit of information 
strictly used for memory management "invisible" to the user's 
program and is of a "fixed size", In this design only segmen- 
tation 1S supported by both the hardware and software. 

Segmented memory management can offer several 
advantages. It can: control fragmentation; facilitate shared 
segments (data areas and procedures); and also for future 


development in this system can provide dynamic linking and 
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FIGURE 3. SEGMENTED ADDRESSING 
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loading, controlled access, dynamically growing and shrinking 
segments. More details about segmentation in the present 
design will be discussed in the next chapter. 
4. Abstraction - Abstract types 

"Abstraction" provides a method for reducing problem 
complexity by applying a general solution to a collection 
of specific cases [{17]. Structured programming provides a 
tool for creating abstraction in software design. 

An “abstract type" is a class of objects in the 
system, for which there is a defined set of operations. 
The difference between an abstract type and the "classic" 
notion of type, is that the user of an abstract type need 
not know the representation of the object or the algorithms 
used to implement operations defined on the type, and 
furthermore, the only operations allowed to be performed 
on the object are specified by the definition of the type. 

The concept of abstract type is quite attractive for 
the structuring of large systems. The result is the kind of 
structuring prescribed by Parnas' "information hiding 
principle" [20], for decomposing a system into modules. 
Further, abstract types fit naturally into the structure of 
an operating system since a major task of an operating system 
1s to multiplex a set of physical resources to produce a set 
of virtual resources that can be viewed as objects of abstract 
type. For example, this 1s exactly what happens in processor 


multiplexing (see paragraph C). 
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An abstract type consists of a set of objects anda 
set of operations. For example, a word in virtual memory 
is an abstract type. Two operations that can be carried out 
by instructions in user processes are read~-word, which 
obtains the content of a word named by a particular virtual 
memory address, and write-word, which takes a bit string and 
stores it in the object specified by a particular virtual 
memory address. Processors, both real and virtual, also can 
be viewed as objects of abstract type. 

The abstract type idea clearly furnishes a useful 
way to view the virtual objects seen at an operating system, 
but for the design of an operating system the abstract idea 
is equally important in structuring the internal implementa- 
tion of the system. 

By strictly applying two special rules in addition 
to the general principles of structured programming, a 
structure consisting of levels of increasing abstraction can 
be constructured. 

First, calls cannot be made outward toward higher 
levels of abstraction. This frees lower levels from a 
dependence on higher levels by creating a loop-free structure 
and results in a design which is capable of having subsets. 

Second, calls to lower levels must be made through 
specific entry points or gates. Each level of abstraction 
creates a virtual (hierarchical) machine [13]. The gate to 


each level provides a set of instructions created for that 
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virtual machine. Thus, higher levels may use the resources 
of lower levels only by applying the instruction set of a 
lower level machine. Once a level of abstraction has been 
created, the details of its implementation are no longer an 
issue. Instead users see layers of virtual machines, each 
defined by its extended instruction set. 

For this particular design when the rules of 
abstraction are applied to level 9, the physical resources 
of the system, these resources are "virtualized". Thus 
the first level of abstraction creates "virtual processors", 
"virtual memory", and "virtual devices" from the system's 
hardware. At each higher level the detail of the design 
is reduced. The gate at the boundary between the highest 
level of the kernel and the lowest level of the supervisor 
provides a mechanism for isolating the kernel as well as 
ensuring that each memory access is via kernel software. 
This mechanism has been implemented in the system by a ring- 
crossing mechanism called the Gatekeeper (or Gate). 

5. Protection Domains - Levels of Abstraction 
a. Protection Domains 
The implementation of this operating system has 
not considered the "internal security" of the system but in 
the design there are all the ingredients for future extensions 
iietais direction. 
An essential requirement [22] of internal security 


is that the security kernel be isolated from other elements 
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of the system. This can be accomplished by the construction 
of protection domains. Protection domains are used to 
arrange process address spaces into rings of different 
privilege. This arrangement is a hierarchical structure 
in which the most priviledged domain is the innermost ring. 
The structure essentially divides the address space into 
levels of abstraction with strictly enforced gates at the 
ring boundaries (Figure 4). 

The protection provided by the ring structure 
is not a security policy (Security protection is implemented 
by a lattice structure). It is, however, a mechanism to 
enforce the hierarchy of the virtual machine by creating a 


priviledged kernel ring within the supervisor ring. 
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In this implementation to protect kernel proced- 
ures from the user, the process‘ address space is divided 
into two hierarchical domains, "user domain" and "kernel 
domain". The kernel domain is the most priviledged. Only 
the kernel executes in this domain. The user domain is less 
priviledged and is separated from the kernel domain to protect 
the user from inadvertently causing problems to the operating 
system services. These two domains are generated by software 
Since there is no hardware support. 

b. Levels of Abstraction 

Abstraction iS a way of avoiding complexity and 
a tool by which a finite piece of reasoning can cover a 
myriad of cases [17]. The purpose of abstracting is not to 
be vague, but to create a semantic level in which one can be 
absolutely precise. 

Levels of abstraction have been demonstrated to 
be a powerful design methodology for complex systems. The 
use of levels of abstraction in general leads to a better 
design, with greater clarity and fewer errors. 

A level is defined not only by the abstraction 
that it supports (for example, a segmented virtual memory) 
but also by the resources employed to realize that 
abstraction. Lower levels (closer to the hardware) are 
not aware of the abstractions, or resources of lower levels 
only by appealing to the functions of the lower levels. This 
pair of restrictions reduces the number of interactions among 


parts of a system and makes them more explicit. 
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Fach level of abstraction creates a virtual 
machine environment. Programs above some level do not need 
to know how the virtual machine of that level is implemented. 
For example, if a level of abstraction creates sequential 
processes, and multiplexes one or more hardware processors 
among them, then at higher levels the number of physical 
processors in the system is not important. This way, in 
present implementation, since the processes are assigned 
virtual processors (and not physical), there is no effect 
on the user when real processors are added or deleted 
(except, of course, for the change in performance). Adding 
and deleting processors will have particular interest when 
"fault tolerance" and "fault correction" are added to the 
attributes of the operating system. 

On the present implementation, the operating 
system is structured as a hierarchy of the levels of abstrac- 


Elon shown in Figure 5. 


C. PROCESSOR MULTIPLEXING 
1. Definition of a Processor 
The basic function of a processor is to perform a 
sequence of operations on objects in its environment. The 
environment of a processor is a set of objects. For example, 
the environment of a physical processor is that portion of 
memory that it can access through its address mapping hard- 


ware. Typically the environment is specified by an object 
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such as the "descriptor segment" (in MULTICS) which in turn 
names another object. 

A processor has internal memory, called its state, 
that it uses to pass information from one operation to the 
next. The processor determines the next operation to perform 
by interpreting an instruction found in the processor's 
environment by an instruction pointer that is part of the 
processor state. Also included in the processor state is 
the name of the current domain in which the processor is 
executing. 

Each operation performed may modify the contents 


of the processor's internal memory. In particular, it changes 
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the instruction pointer to select the next instruction to 
be interpreted. 

As an object of abstract type, a processor may be 
part of the environment of other processors. The operations 
that can be performed on a processor object are: loading 
a new state into the processor, extracting the current state 
from the processor, causing the processor to run, causing 
the processor to stop, etc. 

A processor can be a physical object such as the 
INTEL 8086, 16-bit general-purpose microprocessor used to 
implement this design. In this case, the processor registers 
comprise the state of the processor. The environment of the 
processor includes all of the primary memory that is acces- 
Sible through the processor's descriptor segment. The 
descriptor segment in this design is related to the four 
hardware segment registers (CS, DS, SS and ES). Details 
are discussed in the next chapter. 

On the other hand, a virtual processor which has 
no direct hardware manifestation, is a Simulation of a 
physical processor achieved by using physical processors 
to interpret the instructions to be executed by the virtual 
processor. The virtual processor idea is discussed in the 
following paragraph 3. 

2. Definition of Processor Multiplexing 
Multiplexing can be defined as the use of a single 


resource for different purposes at different times. For 
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example, the physical bus lines can be used both for addresses 
and data during different times of a machine cycle. 

Processor multiplexing is a technique for sharing 
scarce processor resources among a number of processes. The 
ability to multiplex processors efficiently provides a 
mechanism for the virtualization of these physical processors 
by Simulating the existence of a larger number of virtual 
processors. This technique is widely used in conventional 
uniprocessor systems where it is called multiprogramming. It 
seeks to maximize the use of the available hardware by auto- 
mating control of process loading and execution. It also 
greatly increases the flexibility of a system allowing it 
to be effective in more complex and demanding applications. 

J. H. Saltzer [14] presented one of the fundamental 
works on the subject of processor multiplexing. 

3. Processor Virtualization 

The first levels of abstraction, above system hard- 
Ware, creates virtual representations of physical resources 
(virtual processors, virtual memory). Since upper levels of 
the design operate on these virtual processors rather than 
on physical processors, most of the design (i.e., everything 
above virtualization level) is independent of the physical 
configuration of the system. This means that by providing 
the virtual to real processor binding in the kernel of the 
operating system and since the processes are assigned virtual 


processors (and not real processors), there is no effect 
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on the user when real processors are added or deleted in the 
system (except, of course, for the change in performance). 

The physical processor resources (those hardware 
devices that execute machine instructions) are virtualized 
by creating abstract processors called virtual processors. 

Processor multiplexing can be defined also as a 
Simulation of a number of distinct virtual processors by a 
smaller number of real processors. 

a. Virtual Processors 

A virtual processor is a data structure that 
contains a complete description of a process in execution on 
a physical processor, at a given instant. This description 
is contained in the process execution point. The address 
space of the process must be accessible to the virtual 
processor when it is "loaded" on ("bound" to) a CPU. To 
provide a useful virtualization capability, the CPU must 
have the ability to efficiently multiplex process execution 
points and address spaces (i.e., it must support 
multiprogramming). 
Virtual processors are Simulations of processors. 

They can be viewed in essentially the same way as physical 
processors, in that they execute the same instructions. 
However, the instruction set of a virtual processor has been 
expanded to include some instructions which the physical 
processors do not directly have. These include "instructions" 


to "load" a process, certain operation called interprocess 
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communication and synchronization primitives, system service 
calls, etc. 

For example, the AWAIT operation is not an 
Operation that requires real processor resources, it is 
rather an operation that inhibits use of real processor 
resources by the virtual processor. 

Virtual processors exist only as "abstract" 
processors represented by a data structure. They are used 
as the vehicle for the control and manipulation of processor 
resources. 

Each of the virtual processors executes a sequence 
of operations in time. These sequences are actually 
performed by the real processors. Successive operations of 
the same virtual processor may be separated by a gap of 
time, during which operations of another virtual processor 
are being executed by the real processors. Figure 6 shows 
how the operations of three virtual processors might be 


mapped into the operation sequence of one real processor 
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FIGURE 6. MULTIPLEXING A REAL PROCESSOR 
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To define a term used frequently in this thesis, 
a virtual. processor being simulated by a real processor is 
"bound" to that real processor whenever its process is 
being executed by the real processor. Thus, Virtual Proces- 
sor #2 in Figure 6 is bound to Real Processor #1 during the 
first time interval. 

Processor multiplexing also requires a policy of 
scheduling. Given a number of virtual processors to which a 
real processor may be bound at any one time, the real 
processor can execute only one virtual processor. The 
choice of the processor to run is made by some algorithm 
called virtual processor scheduler. This algorithm receives 
aS input the set of virtual processors belonging to this 
real processor and chooses which one is to run (be bound and 
execute). 

4, Multiprogramming 
Multiprogramming is used to improve system efficiency 

and to create a virtual environment which frees the remainder 
of the operating system from a dependence on the physical 
processor configuration. Processor management provides a 
means of coordinating the interaction of the asynchronous 
processes which comprise the system. This implementation 
employs a processor multiplexing technique for a distributed 
kernel and provides a virtual interrupt mechanism. The 
modular hierarchical structure of the software is "loop-free" 


to support future system expansion to higher level functions. 
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The clean, logical, process-oriented structure of the 
system offers other benefits as well, including possible 
inclusion of fault tolerance, resource configuration 


independence, and efficiency. 


In a system where there are more processes than 
processors, there must exist a means of switching processors 
from process to process. For example, reasons for switching 
processes are: current process completes, current process 


is blocked, a higher priority process is ready to run, etc. 


Whatever the reason for switching, there are certain 
tasks that must be done in performing the switch. First, 
Save the address space and current execution point of the 
Old process. Secondly, load the address space and the 


execution point of the new process. 
5. Multiprocessing 


The process structure provides the essentials for 
parallel processing. That is the support for a set of 
asynchronous processes which can communicate with each other. 
Parallel processing does not require a multiprocessor 
environment. However, in a multiprocessor environment, 


parallel processing can provide faster completion of a job. 


Whenever a job depends on a mixture of asynchronous 
and synchronous tasks and time is a factor, then concurrent 
processing is a possible solution to get the job done in 
the specified amount of time. Using several processors 
working on the same job and each of them doing separate tasks, 
the overall time required to to this job can be reduced (job 


has been structured into explicit processes). 
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The above discussion provides some of the major 
reasons why this system was designed to support parallel 
processing on multiple processors. 

6. Two-Level Processor Multiplexing 

In this design there are two levels of processor 
multiplexing. The design in two levels arose from the 
existence of multiple physical processors. Each of the 
levels addresses a distinct requirement. One level supports 
Virtual processor management, that is, the provision of 
inter-process communication and synchronization. The 
other supports the management of physical resources by the 
operating system. The first one addresses the multiplexing 
of virtual processors among processes and is the "Traffic 
Controller". The other addresses the multiplexing of 
physical processors among virtual processors and is the 
mummers Traffic Controller". 

a. “elhewiratitze Controller 

The Traffic Controller represents the upper 
level of processor multiplexing (Level 2) and provides the 
mechanism for multiplexing virtual processors among processes. 
Thus it is responsible for inter-process synchronization and 
communication. 

As an example, consider that a Process A wishes 
to synchronize its actions with another Process, B, such 
that Process B has to complete some task before A can 


continue execution. Thus A will execute to the point where 
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it cannot. proceed further and then wishes to signal B. 
When Process B has finished that task it must notify Process 
A of its completion so that Process A may then proceed. 

This inter-process synchronization and communica- 
tion is handled at the level of the Traffic Controller. [In 
the above example, when Process A discovered that it could 
not proceed further, it "gave away" its virtual processor to 
another process that could be run. In this way the Traffic 
Controller suspended the execution of Process A and a new 
process was bound to its virtual processor. In the same 
way, when B completes (viz., it has no more work to perform) 
it will also give its virtual processor away. 

m. _the Inner Traffic Controller 

The Inner Traffic Controller comprises the 
lower level of processor multiplexing (Level 1) and provides 
the second set of multiplexing functions. It multiplexes 
physical processors among a fixed set of virtual processors. 
In particular, the system's interrupt structure is managed 
Myethe inner Traffic Controller. 

If a user process calls upon some system service, 
Such as disk I/O or I/O for a real-time sensor, it must wait 
for that service to be completed before it can proceed. The 
performance of a system service is considered to be part of 
the requesting processes. However, the service may actually 
be supported by another virtual processor. To control this 


interaction, the Inner Traffic Controller provides the 
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required inter-virtual processor synchronization and communi- 
cation mechanism. In particular, a physical system interrupt 
is directly transformed into a synchronization signal to a 
waiting virtual processor. This structure is particularly 
important for the support of real-time processing, and note 
that it is completely distinct from inter-process synchroni- 
zation and communication described in paragraph 6a. 

7. Processor Multiplexing Strategy 

a. Process State Transitions 

Figure 7 illustrates the state transitions of 
a set of processes as a virtual processor is multiplexed 
among them. Some eligible process (one which is in the ready 
State) is scheduled to run and is "bound" to the virtual 
processor. At this time, the process makes the transition 
to the running state. As far as the process is concerned, 
once it enters the running state, it is executing. 

At some point in its execution, the process may 
desire to block itself or signal another process. (For 
example, when Process A is at that execution point and needs 
data computed by another Process, B.) In that case, it will 
block itself (will enter the blocked state) and will "give 
up" the virtual processor to which it is presently bound and 
will be out of "contention" for processor resources. It will 
remain in the blocked state until some other process will 
Signal it. (In the above example, when Process B has computed 


the needed data for Process A.) Then this process will make 
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the transition back to the ready state. If the process 
Signals other processes, it will make a transition from the 
running state back to the ready state from which it may be 
scheduled to run again. In doing so, it allows the Traffic 
Controller to possibly give the virtual processor to some 
other higher priority process which may be ready to run. 

The mechanisms which decide and permit these 
transitions are the Traffic Controller Scheduler and the 
Traffic Controller inter-process synchronization and communi- 
cation primitives AWAIT, ADVANCE. Their details will be 
discussed in Chapter IV. 

b. Virtual Processor State Transitions 

Figure 8 illustrates the state transitions made 
by the virtual processors as a physical processor is 
multiplexed. This diagram is very similar to that of Figure 
7. However, these transitions are not directly observable 
by processes except in the differences of their execution 
times, aS virtual processor state transitions result from 
the management of physical resources by the operating 
syscem. 

A running virtual processor can make a transition 
to the waiting state or to the ready state. The transition to 
the waiting state occurs when a virtual processor must wait 
for the completion of some system service (analogous to the 
blocking of Process A in the example given in paragraph a). 


The transition from running state back to ready state occurs 
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when the running virtual processor signals other virtual 
Processors. It will allow the Inner Traffic Controller to 
possibly run another higher priority virtual processor. 

While in the waiting state, the virtual processor is out of 
"contention" for processor resources until another virtual 
processor signals it to continue. While in the ready state, 
the virtual processor 1S in contention for processor resources 
and so may be scheduled to run on the physical processor. 

The mechanisms which decide and permit these 
transitions are the Inner Traffic Controller scheduler and 
the Inner Traffic Controller inter-virtual processor synchro- 
nization and communication primitives AWAIT, ADVANCE. Their 


details will be discussed in Chapter IV. 


D. COMMUNICATION AND SYNCHRONIZATION 

For concurrent processing, a job that is composed of 
sequential and non-sequential tasks is explicitly divided 
into an appropriate structure of processes that can run 
concurrently. Inter-process communication and synchroniza- 
tion are necessary for concurrent processing. 

It is the responsibility of the operating system to 
provide mechanisms for communication between cooperating 
processes. There are two different kinds of communication 
that processes must be able to achieve. 

There must exist a way for processes to exchange data 
in some way. This mode of communication is called inter- 
process communication. 


De. 





There must also exist a way for processes to wait for 
data prepared by other processes, and for processes that 
prepare such data, to signal that this data is available. 

This interaction is different than communication of data, 
and is called inter-process synchronization. Together these 
two modes are called inter-process communication and 
synchronization. 

The actual coordination for the exchange of data between 
processes is realized by the use of "Shared writable" segments. 

Therefore, to utilize the parallelism and pipelining 
afforded by multiple processors, a mechanism is required for 
inter-process communication and synchronization. It is used 
for controlling the execution of processes and coordinating 
the sharing of data. 

The most widely used synchronization primitives are 
Dijkstra's semaphores [11] or Saltzer's Block and Wakeup [14] 
that were used in O'Connell and Richardson's original 
design [7]. However, the design decision was made to use 
a different mechanism which provides automatic "broadcasting", 
supports "parallel signalling" and addresses the questions of 
"confinement" (or * property) in a secure system. This is the 
synchronization mechanism based on the design of eventcounts 
and sequencers of Reed and Kanodia [10]. 

The synchronization between processes is supported by 
the AWAIT and ADVANCE, that are the kernel calls to the 


Metric Controller level. The Traffic Controller is the 
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kernel module that manages processes and supports scheduling 
for user processes by multiplexing the user processes into 
a limited (fixed) number of virtual processors. 

AWAIT and ADVANCE are primitives of the Traffic 
Controller. These primitives can be used to provide simple 
cooperation, such as mutual exclusion or complex inter- 
actions, when required by the application. How the user's 
procedures invoke the AWAIT and ADVANCE primitives depends, 
of course, on the actual process structure. (Examples will 
be given in Appendix A). 

A process can only block itself (using AWAIT) and cannot 
block another process. The AWAIT sets the "calling process" 
that invoked AWAIT in the blocked or ready state and then 
the Traffic Controller Scheduler schedules another ready 
process to run, the highest priority ready process. 

The ADVANCE is used to provide asynchronous processes 
with a synchronization signal. The ADVANCE takes as parameter 
the name of the associated eventcount. It advances the value 
of that eventcount by one. This incrementation of the even- 
count value is "broadcast" to all the processes waiting for 
that event. Then a check is made to determine if the awaited 
eventcount value (for the processes waiting that event) is 
Smaller or equal to the current value of the eventcount. If 
this is the case, then these previously blocked processes 
will awake and resume the ready state. Otherwise they will 


remain blocked. Then a check is made to find out if the 


io Be 


currently running process is of lower priority than the other 
ready processes (after ADVANCE operation). If that is 

the case, the ADVANCE will send to the virtual processor 
(which is running this lower priority process) a "pre-empt 
interrupt". Finally the scheduler will select the highest 
priority ready process to run. So, we see that the ADVANCE 
is also responsible for operating the "pre-emption 
mechanism". 

The above describes roughly the idea of AWAIT and 
ADVANCE primitives, which are very close to the BLOCK and 
WAKEUP described in O'Connell and Richardson's thesis [7]. 
More details and the whole operation of eventcounting will 
be discussed in Chapter IV. 

Another system level concerned with synchronization is 
the Inner Traffic Controller. This level manages the physical 
(real) processors to create the virtual processors, that are 
in turn managed by the Traffic Controller. 

The Inner Traffic Controller provides the interface and 
does the multiplexing among the physical (real) and virtual 
processors. Each physical processor has associated with it 
several (a fixed number) of virtual processors. Some of 
these virtual processors are mutliplexed in turn by the 
Traffic Controller among user processes. Each system process 
is assigned (dedicated to) a virtual processor. In the current 
implementation there are two such processes, and these will 


be discussed in Chapter IV. 
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The Inner Traffic Controller decides which virtual 
processor will run on the physical processor, based on the 
priority assigned to each virtual processor. Of course 
from the number of virtual processors assigned to a real 
processor only one can run on it at a time. The primitives 
ITCSAWAIT (Inner Traffic Controller AWAIT) and ITCSADVANCE 
(Inner Traffic Controller ADVANCE) are used to provide 
communication and synchronization among the virtual 
processors. These primitives are very similar in form 
and function to the AWAIT and ADVANCE of the Traffic 


Gemtroller. 
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Peewee OChSoOR ARCHITECTURE 


The manifestation of an operating system design is, of 
course, software in execution on a system of equipment. If 
the equipment must be selected early in the design, care 
must be taken to insure that the overall system design goals 
are compatible with the actual hardware capabilities. On the 
other hand, if specific design goals must be met, then actual 
hardware selection could be made late in the design process. 
Then, even if a hardware change must be made, the penalty for 
correcting it will be small, since only the lowest level of 
the design (where resources are virtualized), need be changed. 

The particular hardware selected for this implementation, 


is based on the INTEL 86/12A single board microcomputer [2]. 


A. HARDWARE REQUIREMENTS 

One of the principal design goals of the system design 
is to provide for configuration independence. That is when 
real processors are added or deleted the system will continue 
to function except of course for some change in performance. 
Therefore, the operating system imposes only a few constraints 
on the hardware, that are noted below: 

i. Sohaned Global Memory 

The operating system maintains, "system-wide control 


data" accessible to each of the processors via "shared" 
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segments. The communication path utilized for sharing this 
data is shared memory. Thus some shared memory must be made 
available to each microcomputer in such a way as to allow 
independent access at the level of single memory references. 
(a very small part, of a separate memory board (MUPRO) is used 
as shared global memory, in this system implementation). 
2. Multiprocessor Synchronization Support 

There must also exist some "hardware-supported multi- 
processor synchronization primitive". This can be any form 
of an indivisible read-alter-rewrite memory reference. This 
capability is required, to implement the global locks on 
Shared data to prevent race conditions, as the physical pro- 
cessors attempt to asynchronously manipulate shared data. 
For better understanding of this and the previous paragraph, 
consider the following cases of APT and VPM. Two of the 
system-wide data control tables are the VPM (Virtual Processor 
Mapping) and the APT (Active Process Table), as shown in 
Figure 9. VPM is the principal central data base for the Inner 
Traffic Controller which contains entries for all of the 
virtual processors in the system. Each entry (there is one 
"per virtual processor") has several fields, such as the 
muetndal processor state, priority, etc., which will be 
described in Chapter IV. 

Making this table globally available facilitates 


communication among virtual processors at the Inner Traffic 
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Gontroller level, on a “system-wide” scale, since every 
virtual processor can access this table. 

But to prevent race conditions, and also to assure 
that only one processor, at a time, accesses the VPM, as the 
physical processors attempt to asynchronously manipulate 
shared data, we see the need of a global lock for VPM table. 
So in the implementation (coding), every time the VPM is 
accessed either to read data or to write, e.g. update a 
field, conceptually a "key" is turned and the VPM table is 
locked. When the access task is finished, before leaving 
we unlock the VPM. 

Exactly the same concept is applied for the APT, 
which is the principal central data base for Traffic 
Controller in LEVEL 2, containing entries for every process. 

In the implementation of this design (coding), we 
can see that modules accessing VPM, as for example, ITCSAWAIT 
and ITCSADVANCE, and also modules accesSing APT, as TCSAWAIT, 
TCSADVANCE and TCSPESHANDLER (Traffic Controller Preempt Hand- 
ler), lock and afterwards unlock the corresponding global table. 

To set these global locks, the implementation of the 
present design utilizes the "test-and-set semaphore" oper- 
ation. This mechanism, supported by the PL/M built-in 
procedure "Lockset" [1], is a spin-lock with potentially 


Significant impact on system bus traffic. 
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3. Inter-Processor Communication 
Finally, some method of communication between physical 
processors must be provided. This is satisfied by an ability 
to generate interrupts between the physical processors. This 
capability is required for the implementation of "Preemptive 
scheduling" and is supported by the INTEL SBC 86/12A using a 


specific hardware configuration and software control. 


B. HARDWARE CONFIGURATION 
1. System Configuration 
The hardware system is configured as a multi- 
processor [18]. It consists of a number of single board 
microcomputers and a global memory module, connected by a 
Single shared bus. The system differs from conventional 
multiprocessors in that each of the microcomputers possesses 
its own local memory. The global memory module is connected 
directly to the system bus, and is the only physical shared 
memory resource by all of the processors. The general con- 
figuration is shown schematically in Figure 10. 
2. Specific Hardware Employed 
The particular hardware selected for this implemen- 
tation is based on the INTEL 86/12A single board micro- 
computer [2]. This microcomputer utilizes the INTEL 8086 
16-bit microprocessor capable of directly addressing a total 


of 1 Mega-byte of physical memory. 


62 








LOCAL 


MEMORY 
CPU 
LOCAL : 
MEMORY 
CPU 
9 
; GLOBAL 
8 
8 
MEMORY 
LOCAL 
MEMORY 
CPU 
LOCAL 
MEMORY 
CPU 


FIGURE 10. MULTIPROCESSOR CONFIGURATION 


6 3 





a. The 8086 Microprocessor 

The 8086 microprocessor 1S suitable for a wide 
spectrum of microcomputer applications. Systems using 8086 
can range from uniprocessor minimal-memory designs, to multi- 
processor systems with up to several Megabytes of memory. 

The CPU is designed to operate with the 8089 
input/output processor and other processors in multi- 
processing and distributed processing systems. Built-in 
coordinating signals and instructions, and also electrical 
compatibility with INTEL'S MULTIBUS shared bus architecture, 
Support the development of multiple-processors design. 

Actual performance, of course, varies from appli- 
cation to application. But in comparison to the 8-bit 2-MHZ 
8080A, 8086 is seven to ten times more powerful. The high 
performance of the 8086 is realized by combining a 16-bit 
internal data path with a pipelined architecture that allows 
instructions to be prefetched during unused bus cycles. 
Furthermore software for high-performance 8086 systems need 
not be written in assembly language. The CPU is designed to 
provide direct hardware support for programs written in high- 
level languages, such as INTEL'S PL/M-86 which is used for 
the implementation of this operating system design. 

The 8086 instruction set supports direct oper- 
ation on memory operands, including operands on the stack. 


The hardware addressing modes provide straightforward 
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implementations of based variables, arrays, arrays of 
structures, character data manipulation (there is an exten- 
Sive use of all these features in the implementation). 
Finally, routines with critical performance requirements 
that cannot be met with PL/M-86 may be written in ASM-86, 
the 8086 assembly language, and then linked with the PL/M-86 
code. For example, the Virtual Processor Scheduler of the 
Inner Traffic Controller level is written in ASM-86. 
b. Processor Architecture 

Microprocessors generally execute a program by 
repeatedly cycling through the steps shown below: 

(1) Fetch the next instruction from memory. 

(2) Read an operand (if required by the instruc- 
lemon) . 

(3) Execute the instruction. 

(4) Write the result (if required by the instruc- 
fon) . 

The architecture of 8086, while performing the 
Same steps, allocates them to two separate processing units 
within the CPU (see Figure 11). The execution unit (EU), 
executes instructions. The bus interface unit (BIU) fetches 
instructions, reads operands and writes results. These two 
units can operate independently of one another and are able, 
under most circumstances, to extensively overlap instruction 


fetches with execution. 
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The result is that, in most cases, the time 
normally required to fetch instructions "disappears", 
because the EU executes instructions that have already been 
metened by the BIU. 

A 16-bit arithmetic/logic unit (ALU) in the EU 
maintains the CPU status and control flags and manipulates 
the general registers and instruction operands. All registers 
and data paths in the EU are 16-bits wide for fast internal 
transfers. The EU hasS no connection to the system bus, the 
"Outside world". It obtains instructions from a queue 
maintained by the BIU. Likewise when an instruction requires 
access to memory or to a peripheral device, the EU requests 
the BIU to obtain or store the data. All addresses manipulated 
by the EU are 16-bits wide. 

The BIU performs an address relocation that 
gives the EU access to the full Megabyte of memory space. 

BIU performs all bus operations for the EU. Data is trans- 
ferred between the CPU and memory or I/O devices upon demand 
from the EU. In addition, during periods when the EU is busy 
executing instructions, the BIU "looks ahead" and fetches 
more instruction from memory. The instructions are stored 

in an internal RAM array called the instruction stream queue 
(which can store up to six instruction bytes). This queue 
Size allows the BIU to keep the EU supplied with prefetched 


instructions, under most conditions without monopolizing the 
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system bus. The BIU fetches another instruction byte, when- 
ever there are two empty bytes in its queue and there is no 
active request for bus access from the EU (BIU normally 
obtains two instructions bytes per fetch). 

Under most circumstances the queue contains at 
least one byte of the instruction stream, and so the EU does 
not have to wait for instructions to be fetched. The instruc- 
tions in the queue are the next logical instructions as 
long aS, execution proceeds serially. If the EU executes an 
instruction that transfers control to another location, then 
the BIU resets the queue and fetches the instruction from 
the new address, passes it immediately to the EU, and then 
begins refilling the queue from the new location. In addition, 
the BIU suspends instruction fetching whenever the EU requests 
a memory or I/O read or write (except that a fetch already in 
progress is completed before executing the EU's bus request). 

c. CPU Registers 

There are eight 16-bit general registers. The 
general registers are subdivided into two sets of four 
registers each. The first set, called the "H and L" group 
(for "high" and "low"), are the data registers. The second 
set, called the "P and I" group, are the pointer and index 
registers (see Figure 12). 

The data registers have their upper (high) and 


lower (low) halves separately addressable. This means that 
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each data register can be used interchangeably as a 16-bit 
register or as two 8-bit registers. The other CPU registers 
always are accessed as 16-bit units only. The data registers 
can be used without constraint in most arithmetic and logic 
operations. In addition, some instructions use certain 
registers implicitly (see Figure 13), thus allowing compact 
yet powerful encoding. 

The pointer and index registers can also par- 
ticipate in most arithmetic and logic operations. The P and I 
registers (except for BP) also are used implicitly in some 
instructions, as shown in Figure 13. 

The 16-bit instruction pointer (IP) (analogous 
to the program counter, PC, in the 8080 CPU) is updated by 
the BIU, so that it contains the offset (distance in bytes) 
of the next instruction from the beginning of the current code 
segment. IP points to the next instruction. During normal 
execution IP contains the offset of the next instruction 
to be “fetched by the BIU". Whenever IP is saved on the stack, 
it first is automatically adjusted to point to the next 
instruction to be "executed". Programs do not have direct 
access to the IP, but instructions cause it to change and to 
be saved on and restored from the stack. 

The 8086 has six l-bit "status flags" that the 
EU posts to reflect certain properties of the result of an 


arithmetic or logic operation. A group of instructions is 
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IN GENERAL THE FLAGS REFLECT THE FOLLOWING CONDITIONS: 


(l) AF: Auxiliary Carry Flag (6) ZF: Zero Flag 
mm) CF: Carry Flag Cy) on "Dieeection Fiac 
(3) OF: Overflow Flag (8) IF: Interrupt Flag 
(4) SF: Sign Flag (9) TF: Trap Flag 


(5) PF: Parity Flag 


PIGURE 14. FLAGS Tal 





available that allows a program to alter its execution 
depending on the state of these flags, that is, on the result 
of a prior operation. Three additional "control flags" can 
be set and cleared by programs to alter processor operations 
(see Figure 14). 
d. Segmentation - Segment Registers 

The 8086 does not support the notion of explicit 
segmentation. In the 8086, addressing is segmentlike, in 
that the base and offset (two-dimensional) addressing is used. 
8086 programs "view" the one Megabyte of memory space as a 
group of segments that are defined by the application. A 
segment 1S a logical unit of memory that may be up to 64K 
bytes long. Each segment is made up of contiguous memory 
locations and is an independent separately-addressable unit. 

Every segment is assigned (by software) a base 
address which is its starting location in the memory space. 
All segments begin on 16-byte memory boundaries. There are 
no other restrictions on segment locations. Segment may be 
adjacent, disjoint, partially overlapped or fully overlapped 
(see Figure 15). However, in this operating system design a 
physical memory location cannot be mapped on (contained in) 
more than one logical segment. 

The segment registers point to (contain the base 
address values of) the four currently addressable segments 


(See Figure 17). Programs obtain access to code and data in 
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other segments by changing the segment register, to point to 
the desired segment. 

Every application can define and use segments 
differently. The currently addressable segments provide a 
generous work space of 64K bytes for code, 64K bytes for 
Stack, and 128K bytes of data storage. 

The CPU has direct access to four segments at a 
time. Their base addresses (starting locations) are contained 
in the segment registers (See Figure 16). 

In this implementation these four base segment 
registers of the 8086 microprocessor are utilized as follows: 

(1) Code Segment Register (CS register) is used 
for addressing a pure segment containing executable code. 

CS register points to the current code segment. Instructions 
are fetched from this segment. 

(2) Data Segment Register (DS register) is used 
for processing local data. The DS register points to the 
Current data segment that generally contains program variables. 

(3) Stack Segment Register (SS register) is used 
for implementing the per process stacks (kernel stack and user 
Stack). SS register points to the current stack segment. 
Stack operations are performed on locations in this segment. 

(4) Extra Segment Register (ES register) is 


typically used for external or shared data. ES register 
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points to the current extra segment (which also is typically 
used for data storage). 

In the 8086, a Segment can range anywhere up to 
64 kilo-bytes in length. Segments can be placed anywhere 
within the 1 mega-byte address space of the 8086 as long as 
the segment hexadecimal base is placed so that the last digit 
of the base 1S zero. Segment access and bounds checking 
are not Supported. Although there is no general segmentation 
hardware, this design effects a segmented address space 
through a combination of operating system support and system 
initialization conventions described in a thesis by 
Anderson [19]. 

e. Physical Address Generation 

It is useful to think of every memory location 
having two kinds of addresses, "physical" and "logical". A 
physical address is the 20-bit value that uniquely ident- 
ifies each byte location in the Megabyte memory space. 
Physical addresses may range from OH through FFFFFH. All 
exchanges between the CPU and memory components use this 
physical address. 

Programs deal with the logical rather than 
physical addresses and allow code to be developed without 
prior knowledge of where the code is to be located in memory 


this facilitates dynamic management of memory resources. 
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A logical address consists of a segment base 
value and an offset value. For any given memory location 
the segment base value locates the first byte of the con- 
taining segment and the offset value is the distance in 
bytes of the target location from the beginning of the 
segment. 

Segment base and offset values are unsigned 
16-bit quantities. The lowest-addressed byte in a segment 
has an offset of 0. 

Whenever the BIU accesses memory to fetch an 
instruction or to obtain or store a variable, it generates 
a physical address from the corresponding logical one. This 
1s done (see Figure 19) by shifting the segment base value 
four bit positions to the left and adding the offset. 

f. The iSBC 86/12A Single Board Microcomputer 

The 86/12A is a complete computer capable of 
"stand-alone operation" used as the basic processing node of 
the multiprocessor. The iSBC 86/12A Board includes a 16-bit 
central processing unit (CPU), 32K bytes of dynamic RAM, a 
serial communications interface, three programmable parallel 
I/O ports, programmable timers, priority interrupt control, 
Multibus interface control logic, and bus expansion drivers for 
interface with other Multibus interface compatible expansion 
boards. Provision has been made for user installation of up 


to 16k bytes of read only memory (ROM). iSBC 86/12A is a 
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commercial product which satisfies the three basic hardware 
requirements for this operating system mentioned in above 
subparagraph A (HARDWARE REQUIREMENTS). First, it must 
possess a system bus interface. Each microcomputer is capable 
of independently accessing a global shared memory via the 
system bus. Secondly, the 8086 CPU supports multiprocessor 
synchronization directly with an indivisible "test-and-set 
semaphore" instruction, which performs the bus lock. Lock 
semaphores reside in the shared global memory. Thirdly, 
preempt interrupts can be generated by using a bit of a 
parallel I/O port provided on each microcomputer. This 
requires connecting a bit of the microcomputer's parallel 
I/O port to the system interrupt structure. 
g. Preempt Interrupt Hardware Connection 

As with most microprocessors, the 8086 itself 
does not possess the capability to directly generate interrupts 
destined for other devices. The devices of interest here are 
the other processors. We need this capability for the 
implementation of preemptive scheduling. The system interrupt 
lines are accessible through a jumper matrix [2] located on 
the microcomputers. The parallel I/O output port of each 
1iSBC 86/12A is connected to this interrupt jumper matrix. 
Preempt interrupts are then generated by the system simply 
by outputting a single word, through the parallel port, onto 


the system interrupt lines. 
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Note that only a single interrupt line is 
actually required to implement system-wide preempt interrupts. 
For details see the next chapter. 

h. On Board Bus Structure - System Bus 

The iSBC 86/12A board architecture is organized 
around a three-bus hierarchy: the on-board bus, the dual 
port bus, and the Multibus interface (see Figure 20). Each 
bus can communicate only within itself and an adjacent bus 
and also each bus can operate independently of each other. 
The on-board bus connects the CPU to all on-board I/O 
devices, ROM/EPROM, and the dual port RAM bus. Activity on 
this bus does not require control of the outer buses, thus 
permitting independent execution of on-board activities. 
Activities at this level require no bus overhead and operate 
at maximum board performance. 

The next bus in the hierarchy is the dual port 
bus. This bus controls the dynamic RAM and communicates with 
the on-board bus and the Multibus interface. 

When the on-board bus needs the Multibus inter- 
face, it must go through the dual port bus to the Multibus 
interface. The iSBC 86/12A Board is completely Multibus 
interface compatible and supports both 8-bit and 16-bit 
operations. 

The Intel MULTIBUS [2] is utilized as the system 


bus. It is a widely used commercial product with a published 
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set of standards. This bus is specifically designed to 
Support multiple processors and is fully compatible with the 


microcomputers used. It is utilized without modifications. 


C. HARDWARE ASSESSMENT 

The commercially available 86/12A single board micro- 
computer was chosen because it was specifically designed 
to provide support for multiple processor systems. In using 
the operating system described in the next chapter to manage 
the microcomputer's physical resources, this microcomputer 
is entirely suitable for use as a basic processing node of 
an effective multiprocessor system. For multiprocessor 


interconnections see Figure 2l. 


83 





Bey L2A 
Single Board 
fre rocomputer 





86/12A 
Single Board 
Microcomputer 
Parallel 
1/0 ROM RAM 
“a 

Serial 

I/O CEU 
86/12A : 
Single Board é 
Microcomputer ¢ 


Parallel 





FIGURE 21. MULTIPROCESSOR CONFIGURATION 
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iY. DETAILED SYSTEM DESIGN AND IMPLEMENTATION 


fol RUCTURE OF THE OPERATING SYSTEM 

The distributed modules of the kernel create a virtual 
machine hierarchy which controls process interactions and 
Manages physical processor resources. The kernel is not 
aware of the details of process tasks. It knows each 
process only by a name (as an entry in the Active Process 
Table) and provides processes with scheduling and inter- 
process communication and synchronization services based on 
this process identity. 

The kernel is constructed in terms of layers of 
abstraction. Each layer, or level, builds upon the resources 
created at lower levels. The rules of abstraction described 
in Chapter II were applied to the design of this structure. 

This operating system provides a multiprogrammed multi- 
processor system with segmented process address spaces using 
the hardware described in Chapter III. The operating system 
is structured as a hierarchy of four levels of abstraction, 
as follows: 

Level 3: Supervisor 

Level 2: Traffic Controller 

Level 1: Inner Traffic Controller 

Level 0: Hardware (Bare machine), (See Figure 5). 
Level 0 is the bare machine which provides the physical 


resources (processors and storage) upon which the virtual 


85 


\ 





machine 1S constructed to give the extended machine 
view. 

The remainder of this chapter will describe the level of 
Virtualization (or layer of abstraction) created by each 
distributed kernel module. 

The Inner Traffic Controller (Level 1) forms the first 
level of the hierarchy. It is "closest" to the hardware and 
encompasses the major machine-dependent aspects of the system. 
The Inner Traffic Controller multiplexes the physical 
processors among a pool of more numerous virtual processors. 

Residing at the next level (Level 2) is the Traffic 
Controller, which 1s responsible for multiplexing the virtual 
processors among a larger number of uSer processes competing 
for resources. The user-accessible inter-process communication 
and synchronization primitives (Advance, Await and Ticket) | 
provided at this level allow the user to easily satisfy complex 
system-wide inter-process synchronization requirements. 

The Supervisor resides at the topmost level (Level 3). 

The Supervisor's purpose is to provide common services for 
user processes. In this implementation it only provides a 
Simple assembly language interface to the kernel by having 


a single entry point into the kernel (the Gate or Gatekeeper). 


B. CONTROL OF PROCESSOR MULTIPLEXING 
There are two common schemes for the control of processor 


Multiplexing: "centralized control" and "distributed control". 
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Centralized control is based on the idea of a central 
agent which is responsible for the binding of virtual pro- 
cessors to real processors. All these bindings are caused by 
the action of the central agent. This agent can be viewed 
as a process, since it is a sequential computation that per- 
forms operations on the state of the system. In this scheme 
of control usually this central agent is permanently bound 
to a dedicated real processor. Of course this implementation 
requires some kind of communication channel between the real 
processors and the central agent. 

The main advantage of the centralized algorithm is, "unity". 
Since the centralized scheme is executed as a process permanent- 
ly bound to one real processor, it can be described by a single 
sequential program that makes one decision at a time (that 
means a simply structured processor multiplexing policy). 

An alternative scheme for the control of processor multi- 
plexing is one in which the functions are accomplished by a 
distributed algorithm, executed by each process on all real 
processors. 

The main advantage of the distributed scheme is, "autonomy". 
This autonomy afforded by a distributed system can increase 
the amount of parallel activity (real processors can execute 
in parallel). This scheme also results in a uniform design 
that is identical for every processor. 

The advantages of each scheme are disadvantages of the 


Other. In the centralized case the lack of autonomy prohibits 
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the parallelism afforded by the distributed scheme. On the 

other hand, in the distributed case, the autonomy makes it 

potentially difficult to understand the interaction of the 

multiplexing algorithm executed by different real processors. 
1. Distributing the Operating System 

One of the primary concerns in any multiple computer 
system is the issue of performance. The type of system in 
the present implementation is a multiprocessor with a "single" 
Shared system bus. Thus the most glaring potential "bottle- 
neck" is the system bus. Thus it becomes desirable to 
Minimize accesses to this resource which must be shared by 
all of the real processors. 

The decision was made to "distribute" the operating 
system logically and physically to reduce the "system bus" 
use. Logically the segments of the operating system kernel 
are distributed within (as part) the address space of each 
user process. On the other hand, the performance issue is 
dealt with by physically distributing copies of the kernel in 
the local memories of each of the real processors. This allows 
high-speed access to kernel functions without necessitating 
the heavy use of the system bus for code fetches thus 
reducing "BUS contention". 

Since the operating system is small, the memory wasted 
by distributing a copy of the kernel to each single board 
computer is a small price to be paid to allow performance to 


grow with the addition of real processors. 
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Thus, each computing node can be regarded as "semi- 
autonomous" in that each of the processors schedules itself. 
The modes are still centrally controlled by the set of system- 
wide data tables, kept in the global memory, which provides 
access to all real processors and thus eliminates the need of 
a central controlling process. The amount of memory needed 
for these system-wide data tables is almost negligible. 

In this implementation there is no notion of a master- 
slave relationship among individual microcomputers, nor are 
individual kernel functions divided among them, as is 
commonly done. Rather, the "entire" kernel is distributed on 


each single board computer. 


C. REAL TIME PROCESSING 

Real-time control systems are designed for handling data 
within a time period which is consistent with the response 
time demanded by the process which generated the information. 
Such systems operate in a multi-programmed environment where 
the execution of a number of tasks is determined by the soft- 
ware priorities, hardware interrupts, timing algorithms and 
requests from other tasks (requests from one task to start, 
Suspend or terminate another task) to pass data from one task 
to another. 

A real-time operating system must be designed so that it 
is impossible for any program and any user to interfere with 


the execution of critical tasks by halting the machine, by 
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Shanging interrupt priorities or by innappropriately overwriting 
memory. 

Real-time processing involves the performance of time- 
critical processing often related to the control of external 
devices. This application requires that some mechanism be 
employed to ensure that the time-critical processing is 
given immediate attention. 

The hardware-supported "process preemption" mechanism 
employed in the system provides the rapid response required 
for real-time processing. The priority-driven preemptive 
scheduling technique used provides for expeditious handling 
of processes which perform the time-critical functions. These 
processes are asSigned high priorities so that the system will 
preempt other processes of lower priority which may be in the 
running state. Thus when one of these high-priority processes 
is signalled, it can be immediately scheduled and thus gain 
control of the processor resources. 

The actual system response time for a task request depends 
mainly on whether or not another task is running at a higher- 
priority level. To prevent high-priority tasks from executing 
BOO long, a “watchdog timer" is often used to guarantee that 
all tasks are serviced. This timer 1s set at the start of each 
task with the maximum duration that a task may run ata 
particular priority level before being suspended or dropped. 
This watchdog timer is not yet implemented but it will be a 


useful added capability. 
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D. SCHEDULING 

Processor multiplexing and process multiplexing require 
@ policy, called the Processor/Process multiplexing policy 
algorithm, or simply "Scheduling" algorithm. 

In this design the scheduling functions are divided 
between the Inner Traffic Controller and the Traffic Control- 
ler levels. The Inner Traffic Controller multiplexes Virtual 
Processors among Real Processors. Each Real Processor 
possesses a fixed number of Virtual Processors (4 in the 
current version). At any one time the Real Processor can 
only execute "one" Virtual Processor. The choice of the 
Virtual Processor that will run in each Real Processor is 
decided by the Virtual Processor Scheduler (VPSCHEDULER) 
that is a routine in the Inner Traffic Controller level. 

The Traffic Controller multiplexes Processes among Virtual 
Processors. The Traffic Controller Scheduler (TCSSCHEDULER) 
is responsible for that scheduling. Both scheduling algorithms 
are "priority driven". (The highest priority Virtual Processor 
Or Process will run first). These algorithms receive as input 
the set of Virtual Processors and Processes respectively, that 
can be run and choose the next one to run. 

More details will be presented when we will discuss the 


algorithm of these two "scheduler" modules. 


BE. PROCESS ADDRESS SPACE 
The address space of a process is a set of PL/M-86 segments 
Such as procedures (code), local variables (data), external 
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data (shared data) and a stack. Physical memory is allocated 
to the segments of a process in such a way as to limit system 
bus contention, as discussed by Anderson [19]. In this 
implementation the concept of a “per process stack" is a 
key element in the management of processes. 
1. The PL/M-86 Stack 

Intel's high level language PL/M-86 [1,6] utilizes the 
stack segments to implement per process stacks. Addressing 
of stacks is accomplished by using three of the 8086's 
registers as shown in Figure 22. The Stack Segment (SS) 
Register contains the base location of the stack segment in 
memory. The Stack Pointer (SP) Register addresses the current 
top of the stack as an offset from the base of the stack 
segment, (the value in the SS Register). The Base Pointer 
(BP) Register also holds an offset from the SS Register and 
is used to establish the procedure activation records [3, 4, 
5]. During the "process creation" in the current version of 
the operating system one of the parameters passed to the 
Operating system for a specific process is the initial value 
of the SP register ("maximum stack length"). It is used to 
assure no "stack overflow", If the process has only one 
module, the "maximum stack length" can be extracted for the 
specific process during its preparation (Compilation-Linking- 
Locating). Specifically the LST output file of the Compiler 
(file name.LST) at the end provides the information illus-.: 


trated in Figure 23. 
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FIGURE 22. PL/M STACK STRUCTURE 
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There is also a second way to extract this information 
using the MP2 output file of the Locater (file name.MP2). 


This method can be used also when a process consists of 
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FIGURE 23. MAXIMUM STACK SIZE (SAMPLE LST COMPILER OUTPUT) 


several modules linked together. At the end of MP2 file is 


found the maximum stack size as shown in Figure 24. 
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FIGURE 24. MAXIMUM STACK SIZE( BAMPLE MP2 LOCATER OUTPUT) 


To obtain the above “maximum stack size" information the 


command "COPY :FI: File name.LST TO :CO:" is typed on the MDS 


| : 








(INTEL'S Microcomputer Development System) after the compila- 
tion or the command "COPY :Fl: File name.MP2 TO :CO:" after 
the Locating Process. These commands will present the 
Compiler or Locater output file on the CRT screen of the MDS. 
If one prefers to have this output on the printer, just 
meamee “:CO:" to ":TO:". 

In the same way we can extract the information on the 
maximum stack size of the kernel. 

In the current version of the operating system, we use 
two “per process" stacks dividing the "address space" of each 
process into two "domains" of execution and separating the 
"user domain” from the "kernel domain". We call the 
corresponding stacks the "user stack" and the "kernel stack". 

In this version: 
Maximum Kernel Stack Length = 
Maximum Stack Size for the Kernel +10 and 
Maximum User Stack Length = 


Maximum Stack Size for the "User Program""Linked" with 
the "Gate" + 10. 


This value 10 is used to avoid overwriting the "stack 
header" shown on Figure 26 which occupies the first words 
in the stack, just above the stack base. It is important to 
make a distinction between the "User Program" or “Application 
Program" and the "User Process" or Application Process". The 
User or Application program is the "job" submitted to the 


Operating system and the User or Application Process is this 
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program in execution on a processor and is the submitted job 
linked with the distributed part of the Operating system. In 
Figure 25, we can see the User Program as the "subset A" and 
the distributed part of the operating system as the "subset B". 

The running User Process (this program in execution) is 
the "Union C" of these subsets A and B, (C = AUB). This 
connection (linking) of the job with the operating system is 
accomplished via the "Gate." 

Pine stack as the “Add@ress Space Descriptor" 

In this system the per process stacks are used to 
Maintain the process state information. This includes the 
current execution point (when the process is not actually 
running) and the locations of the code and data segments. 

This allows the system to "swap" in a new address space 

(viz., do a "context switch") by changing "only" the value 

in the SS Register which is thus used in a manner somewhat 
analogous to the MULTICS "Descriptor Base Register" (DBR) [9]. 
Then the operating system finds the remaining of the needed 
information to run the specific Process inside its stack. 

Figure 26 shows how this information is stored in the 
kernel stack while a process iS not actually running ona 
physical processor. The Base Pointer and Stack Pointer are 
stored in reserved locations at the very beginning of the 
Stack segment, ("header" of the Stack). Figure 26 illustrates 
the status of the kernel stack after an interrupt within the 


kernel. 
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In order to identify the stack segment and thus 
access the address space of a process, the stack segment base 
address is used ina dual role. First, a "unique base address" 
is assigned to the stack of each process which provides a 
"unique segment" for each stack. This base address is used 
for addressing locations within the stack. Secondly, the 
base address serves as a descriptor for the address space of 
each process. Thus the binding of a processor is changed from 
one process to another "merely" by changing the base address, 
viz., changing the value in the Stack Segment (SS) Register. 
Figure 26 illustrates how the "per process" Kernel Stack is 
implemented in the current version of the Operating System. 
More details about the currently used Stack mechanism (two 
per process stacks, two domains of execution) will be discussed 
when we describe the "Create Process" module of the Traffic 


Controller. 


F. COMMUNICATION AND SYNCHRONIZATION 
1. Process Synchronization 
The problem of process synchronization arises from the 
need to share resources in a computer system. This sharing 
requires coordination and cooperation to ensure correct oper- 


ation. This coordination is forced upon the processes by the 


Operating system because of the scarcity of resources, for 


example, the need to wait for access to an I/O channel. [In 
other cases a simple job may consist of several interactive 


processes, such as an airline reservation system. 
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Associated with processor allocation and interprocess 
Synchronization are two synchronization problems, "race 
condition" and "deadly embrace" or "deadlock situations". 

me Race Condition" 

A race condition occurs when a desired action cannot 
be completed in one indivisible step. For example, in order 
to gain exclusive control of a printer in Process 1 in 
Figure 27, it is important to check if the printer is already 
in execlusive use by Process 2. If a flag is used (F=0, not 


in use) (F=l, in use) to indicate whether or not the printer 









OPERATING 
SYSTEM 
PROCESS 1 


PROCESS 2 


FIGURE 27. A SIMPLE RACE CONDITION 


is in execlusive use, then this flag has to be interrogated. 
If Process 1 interrogates F and finds its value is zero, 
then it can set the value of F to one and enjoy the execlusive 
use of the printer. A problem arises when both Process l 
and Process 2 nearly simultaneously interrogate the flag in 


the following sequence: 
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Process l F=0? Yes 
Process 2 F=0? Yes 
Process 1 Sets F=1l 


Process 2 Sets F=l. 


In this case both processes falsely gain the impression that 
they have exclusive use of the printer. This so called 
"race condition" can be avoided by an indivisible test and 
set operation which would prevent Process 2 being mislead. 
Such a test and lock operation is the 8086 LOCKSET built-in 
procedure. 

In addition to physical devices, there are other 
shared resources, such as a shared database, that require 
the same type of synchronization to avoid race conditions. 
For example, in this implementation in order to avoid race 
conditions in the shared databases APT and VPM, we implemented 
a lock per database. When a Virtual Processor needs to read 
Or update the shared database, it locks this common table 
(this way it locks out all the other Virtual Processors). 
After the completion of this action the Virtual Processor 
unlocks the database, so another Virtual Processor can 
access it. 

3. "Deadly Embrace" or "Deadlock Situations" 

A “deadly embrace" is a Situation in which two pro- 

cesses are unknowingly waiting for resources that are held 


by each other and thus unavailable [15]. See Figure 28. 
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FIGURE 28. DEADLY EMBRACE SITUATION 


"A" and "B" are sharing the use of the printer and card 
reader by means of the request and release operations (as 
stated in the previous paragraph). Due to independent 
scheduling of the processes the "request" and "release" oper- 
ations may be interspersed in several different orders. 

Lets consider a case that starts with Al (request 
printer for process "A") and Bl (request reader for process 
"B"). If then A2 occurs (request reader for process "A"), 
process "A" must be blocked because the reader is already in 


use by process "B". Then when B2 occurs (request printer 
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for process "B"), process "B" must also be blocked because 

the printer is already in use by process "A". In this way 

we confront a situation where each process is waiting for the 
other to release a needed resource. A deadly embrace situation 
is resulted. 

We have already concluded that synchronization primi- 
tives like the described "request" and "release" cannot avoid 
"race conditions" and "deadlock situations". Several more 
sophisticated synchronization primitives have been developed 
to overcome these problems. The most commonly used among 
them are: Dijkstra's "P" and "V" operations on "counting 
semaphores" [12], Saltzer's "Block-Wakeup" or sometimes 
called "Wait-Signal" [14] and lastly Kanodia and Reed's 
"Eventcounts" and "Sequencers" [10]. 

ieeeonared Segment Interactions. Security 

In the paragraph B5 of Chapter II it has been already 
discussed that the implementation of this operating system 
has not considered the "internal security" of the system, but 
in the design there are all the ingredients for future exten- 
Sions in this direction. A future extension also is the 
addition of "file management". We shall mention here two 
more problems which are related to the selection of the 
Synchronization mechanism. 

a. Confinement Property 

During the last five years the security kernel 


technology has demonstrated not only that a kernel can provide 
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security but also that it is practical in terms of performance, 
functional capability, and compatibility. A successful 
implementation of a kernel is based on three [23] engineering 
principles: (1) "completeness", in that all accesses to 
information must go through the kernel; (2) "isolation", in 
that the kernel must be tamperproeof; and (3) "verifiability", 
in that there must be a direct correspondence to the model 

and specification requirements. 

A secure computer system will not occur as a 
Spontaneous result of other design goals. Security must be 
explicitly designed in from first principles, and this is 
the reason why the confinement problem is discussed and has 
influence in the selection of the synchronization mechanism. 

The major problem that has to be handled for 
proper system security is the "confinement property" or 
Beeproperty" [24}. 

The "confinement property" has to prevent a process 
from "reading" a file with a "higher classification" or 
"writing" (1.e., storing or updating) a file with a "lower 
classification". 

b. Readers/Writers Problems 

Another problem closely related to the confinement 
problem which involves the Supervisor, is the “readers/writers" 
problem [25]. In order to preserve file integrity, reading 
and writing of a shared file cannot be allowed at the same 


Eaime. 
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Both the confinement and readers/writers problems 
can be solved in one of two ways. One is mutual excluSion, 

a mechanism which forces a time ordering on the execution of 
Critical regions, forces concurrent processes into a total 
order execution sequence. This is counterproductive to the 
purpose of the process structure of this implementation, 
which inherently allows concurrent execution of processes. 

A second and relatively new method is the use of 
Eventcounts and Sequencers [10] to control access to critical 
regions. This method preserves the idea of concurrent 
processing to a much greater extent and also addresses the 
confinement property for a security kernel. 

Dee oynchronization Background 

In order to keep processor multiplexing simple, it is 
desirable to have a simple interprocess communication and 
Synchronization mechanism. Before describing the "Eventcount- 
ing" synchronization mechanism employed in the design and 
implementation of this operating system, it is worthwhile to 
discuss two generally used synchronization mechanisms, the 
"Semaphore" and "Block-Wakeup". 

a. The "Semaphore" 

In most synchronization schemes, a physical entity 
must be used to represent the resource. This entity is often 
Called a "lock byte" or "Semaphore". Thus, for each "Shared 
database" (for example APT and VPM in this implementation) 


there should be a separate lock byte. We will use the 
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convention that lock byte = 0 means the resource is available, 
whereas lock byte = 1 means the resource is already in use. 
Before operating on such a shared resource, a 
process must perform the following actions with no interrup- 
Lon : 
1. Examine the value of the lock byte (either it is 0 
ea i). 
ye set the lock byte to l. 
3. If the original value was 1, go back to step l. 
After the process has completed its use of the resource, it 
sets the lock byte to zero. Some other terms used for this 
Operation are "Test~-And-Set" instruction, "Software Lockout", 
"Indivisible Read-Alter-Rewrite", "Indivisible Test-And-Set" 
semaphore, "Spin~-Lock" procedure and so on. In this design 
we use a built-in PL/M-86 procedure called LOCKSET, an 
indivisible test-and-set semaphore, to implement software 
locks in shared databases (APT, VPM). The hardware "bus lock" 
is used to make the operation indivisible. It is important 
to note that the lock and unlock operations do, in fact, 
prevent "Race Conditions". 
b. "P" and "V" Operations On Counting Semaphores 
A more general form of the above LOCK/UNLOCK 
mechanism, called the "P" and "V" operations, has been defined 
by Dijkstra (1968). "P" and "V" operate on the "counting 


semaphores" which are variables that take on integer values 
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(but not just 0 and 1). The mechanisms can be defined as 
follows: 

tS) 3 

1. Decrement value of S (1.e., S = S-l). 

2. If S is less than 0, WAIT (S). 

tS): 


1. Increment value of S (i1.e., S S+1). 


2. If S is less than or equal to 0, SIGNAL (S). 

WAIT and SIGNAL are primitives of processor manage- 
ment. A WAIT (S) sets the process to the blocked state and 
links it to the lock byte S. Another process is then selected 
to run by the process scheduler. A SIGNAL (S) checks the 
blocked list associated with lock byte S. If there are any 
processes blocked waiting for S, one is selected and is set 
to the ready state. Then the scheduler will select a process 
eo run. 

In order to implement semaphores in the system, 
the processor multiplexing algorithm must be informed of all 
"V" operations to semaphores, and must keep track of the set 
of virtual processors that are waiting for each semaphore to 
indicate that the event has occurred. 

Unfortunately semaphores have several disadvantages. 
First, they are limited to cases where the occurrence of an 
event will allow a fixed number of virtual processors to 
proceed out of the waiting state. (This mechanism has no 


"broadcast" capability). Second, because of this limitation, 
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the ability to proceed past a "P" operation on a semaphore 
automatically becomes a kind of scarce resource that can be 
used as a communication channel among processes that wait on 
the semaphore. 

This latter point is quite important in a secure 
system design. Although communication of information is 
inherent in the inter-process synchronization mechanism 
between the virtual processor that causes an event and the 
virtual processors that await the occurrence of that event, 
there is no inherent requirement that virtual processors 
waiting for the same event to occur should have a communication 
path among themselves. 

c. "Block-Wakeup" 

This mechanism described in detail by Saltzer 
[14] is quite similar. A discussion of some problems 
encountered with this mechanism is presented in [15]. 

Reed in his thesis [15] notes: 
"If virtual processor A can wake up virtual processor B, 
there is no guarantee that the reason virtual processor B 
is waiting is the reason virtual processor A wakes B up. 
Virtual processor A's wakeup will then be misinterpreted 
by B, or ignored by B. In the first case, B will proceed 
under the false assumption that the event awaited happened, 
while in the second case, B will lose the wakeup (This is 
the case described by Saltzer as the "lost wakeup" problem) 
even though it may be meaningful to B at a later time. 
These problems can be serious for system security, if the 
wakeups are intended for a protected system operation in 
B's virtual processor, because a wait operation executed 
outside of the protected part of the system can receive 
inter-process synchronization signals intended for the 


protected part. The arrival of an inter-process synchro- 
nization signal can carry privileged system information. 
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An unprotected receiver may either gain unauthorized 
access to privileged information, or prevent it from 
reaching its proper destination. These occurrences 
cannot be prevented because B is multiplexing the meaning 
of his wakeup-waiting switch, and so must allow A to wake 
him up at all times, even though B waits for A's event 
only sometimes", 


For these reasons, along with the need to deal 
with synchronization in "distributed" systems, Kanodia and 
Reed [10] have designed an inter-process synchronization 
mechanism that is in some sense more general than either 
semaphores or block-wakeup, and uses "“Eventcounts" and 
"Sequencers". We shall discuss eventcounts and sequencers 
later on in this Chapter. 
6. Communication and Synchronization In This Implementation 
ae 4 Lntroduction 
The design of this operating system supports multi- 
programming and multiprocessing. Multiprogramming is used to 
improve system efficiency and to create a virtual environment 
which frees the remainder of the operating system from a 
dependence on the physical processor configuration. On the 
other hand the process structure provides the essentials for 
parallel (concurrent) processing. In a multiprocessor 
environment concurrent processing can provide faster comple- 
tion of a job. Using n processors working on the same job 
and each of them doing separate tasks (after a suitable 
partitioning of the job), the overall time required to run 


the job can be reduced, frequently by a factor n. 
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The above discussion provides some of the major 
reasons why this system is designed to support concurrent 
processing on multiple processors. In addition, the 
existence of multiple physical processors gave rise to the 
need for the design of processor multiplexing to be done in 
two-levels. The Traffic Controller that multiplexes processes 
among virtual processors and the Inner Traffic Controller 
that multiplexes physical processors among a fixed larger set 
of virtual processors. 

Since this system will also be used to support 
real-time processing, a pre-emption mechanism is provided to 
facilitate preemptive scheduling. 

The above process multiplexing, processor multi- 
plexing, and preemptive scheduling require the following 
Support in communication and synchronization: 

(1) Inter-process communication and synchroniza- 
mion, at the Traffic Controller level. 

(2) Inter-virtual processor communication and 
Synchronization at the Inner Traffic Controller level. 

(3) Inter-real processor communication needed to 
Support the preemptive scheduling. 

b. Inter-Process Communication and Synchronization 

For concurrent processing, a job composed of 
sequential and non-sequential tasks, is explicitly divided 
(partitioned) into an appropriate structure of processes 


eat Can run concurrently. . There is the possibility that 
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after the partitioning the resulting processes must interact 
(need cooperation). 

It is the responsibility of the operating system 
to provide mechanisms for communication and synchronization 
between cooperating processes. There are two different kinds 
of interaction that processes must be able to achieve. 

First there must exist a way for processes to 
exchange data. This mode of communication is called "inter- 
process communication". In a computer system that allows 
Sharing of memory segments between processes (in our case 
Shared segments will reside in the "global" memory board), 
there is no need for a special inter-process communication 
facility to be built into the processor multiplexing algorithm. 
Shared memory segments provide an extremely high bandwidth 
data communication channel between the processes sharing 
these segments. Any protocol for inter-process communication 
can be established by the processes using the shared segments. 
Therefore the inter-process communication will be handled 
outside of the scope of this thesis. The responsibility is 
left to the user of the operating system, since it is dependent 
On the specific application program. 

Secondly there must exist a way for processes to 
walt for data prepared by other processes and for processes 
that prepare such data to signal that this data is available. 
This interaction is different than communication of data and 


1s called "inter-process synchronization". Together they are 
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called "inter-process communication and synchronization". 
Another term for inter-process synchronization is "inter- 
process control communication" since the effect of such 
communication is purely to reenable a waiting control point. 

The actual coordination is realized inside the 
kernel by the use of "shared writable" segments and is used 
for controlling the execution of processes and coordinating 
the sharing of data. 

The synchronization between processes is "visible" 
to the user and is supported by the TCSAWAIT and TCSADVANCE 
that are kernel calls to the Traffic Controller level. We 
have already discussed the basics of these two synchronization 
primitives in paragraphs C6éa, C7a and D of Chapter II. The 
details are described in the corresponding modules of the 
Traffic Controller in this chapter. 

The inter-process synchronization is intimately 
related to the structure of the "processor multiplexing 
Mechanism". The ability of a process to indicate that it 
does not need virtual processor resources until a particular 
"event" happens is basic to the economic advantage of process 
multiplexing among virtual processors. 


c. Inter-virtual Processor Communication and Synchro- 
nization 


The ability of a virtual processor to indicate 
that it does not need real processor resources until a parti- 
cular "event" happens is, Similarly, basic to the economic 


advantage of virtual processors multiplexing among real 
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processors. Otherwise if a dedicated real processor is 
actually available for each virtual processor, then the "busy- 
waiting" would be an adequate mechanism for synchronization. 
("Busy-waiting" is repeatedly testing the state of a shared 
memory word in a loop). 

If for example, a user process calls upon some 
system service, such as a disk I/O or an I/O for a real-time 
sensor, it must wait for that service to be completed before 
it can proceed. (The performance of a system service is, in 
this case, considered to be part of the requesting process). 
However, the service may actually be supported by another 
virtual processor. To control this interaction, the Inner 
Traffic Controller that multiplexes physical processors among 
virtual processors, provides the required inter-virtual 
processor communication and synchronization mechanism using 
the primitives ITCSAWAIT and ITCSADVANCE. 

We have already discussed the basics of these two 
eacmroOnization primitives in paragraphs C6b, C7b and D of 
Chapter II. The details are described in the corresponding 
modules of the Inner Traffic Controller in this chapter. 

This inter-virtual processor synchronization is 
"invisible" to the user, and is used by the operating system 
for the management of physical resources. This mechanism 
provides the solution to a difficult problem: "the 


synchronization" that will be faced later on, when the 
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"Memory Management" and "I/O Management" are added to the 
operating system. 
ad. Inter-Real Processor Communication 

To support real-time processing we need the 
preemptive scheduling. Since we are working ina multiple- 
processor environment the operating system has to support an 
inter-real processors communication mechanism, which is of 
course related to the inter-virtual processors synchronization 
mechanism. It will be explained by the two examples below. 

It is important to note that the preemptive 
scheduling mechanism 1s completely distinct from the synchro- 
nization mechanism and its purpose is to cause the "immediate 
attention" of a real processor when it is needed for real 
time applications. 

The TCSADVANCE and ITCSADVANCE modules provide 
a "broadcast" capability. Let us examine first the case of 
TCSADVANCE. When an application (user) process calls the 
TCSADVANCE, the result 1S an incrementing by one of the 
associated event's current value. This change of the event's 
value is “broadcast" to all processes that are awaiting this 
value for the specific event. We have to remember here that 
the operating system is distributed to each Real Processor 
and also that each real processor in this implementation 
possesses four virtual processors. If a process waiting for 
the above specific event is bound to a Virtual Processor 


which belongs to another real processor, then there is no way 
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Bemsignal that virtual processor to inform it of the occurrence 


of this event. Similarly, if during the physical resources 
management (for example I/O management) the ITCSADVANCE is 
invoked by the operating system (this is “invisible” to the 
user), it results again in an incrementating by one of the 
associated event's current value (now in the Inner Traffic 
Controller level). If this change has to be "broadcast" to 

a Virtual Processor awaiting this event and the Virtual 
Processor belongs to another Real Processor, then again there 
1s no way to inform that Virtual Processor of the occurrence 
of the specific event. 

To facilitate the inter-real processor communica- 
tion, we employ the hardware interrupt. Similar to most 
microcomputers, the 8086 microprocessor does not have the 
capability to send hardware interrupts destined for other 
devices (here the devices of interest are other CPU's). To 
solve the problem we have suitably configured the hardware 
using the on board (8086 microcomputer) hardware chips, 8259A 
Programmable Interrupt Controller and 8255A Programmable 
Peripheral Interface and the Multibus interface. 

This configuration is discussed in detail in 
paragraph G of this chapter. 

e. Events, Eventcounts, and Sequencers 

The ability to synchronize the execution of pro- 

cesses throughout the system (irrespective of which micro- 


computer they are loaded on) is the cornerstone of the power 
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and flexibility of this system. To accomplish this, process 
Semenronization is based on the notion of "events". 

An "event" is anything that one considers signif- 
icant and can direct, in some fashion, the computer to respond 
to. For example events of interest are: the completion of a 
program, a buffer becomes full or empty, a printer 1s ready, 

a process in execution on a VP reaches a control point defined 
by the user. More generally, the events can represent virtually 
anything of interest to the programmer. 

When an event occurs, the computer recognizes that 
it 1s to respond in some specified manner. 

"Eventcounts" and "Sequencers" allow processes to 
synchronize with each other somewhat indirectly. To synchronize 
directly, a process would have to somehow identify the other 
processes with which it is synchronizing (viz., explicitly 
Signal a process by name). This would require the naming of 
individual processes or some Similar identification scheme. 

Rather than using a process naming scheme, the 
individual processes "agree", in a sense, to cooperate by 
uSing a common set of memory objects called eventcounts and 
sequencers. In this way, even though the processes must know 
the names of the eventcounts and sequencers that they use, 
they are not required to know anything at all about each 
other's identities. In fact, a process need not even know 
how many other processes will be synchronizing with it. This 


offers some advantages in parallel processing. Processes that 
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synchronize with eventcounts do not have to know how many other 
processes will also use the same eventcounts. This means that 
fewer coding changes will be required when, for example, a 
single process is partitioned into several processes all 
executing in parallel. All of the “new" processes will 
synchronize on the same eventcount so that no changes are 
required in the process that originally synchronized with the 
Single process. 

Eventcounts are used to keep track of the occurrence 
of specific events. They are managed for the user by the 
system. Sequencers can be used to impose a linear order on 
the occurrence of events. They are thus used with event- 
counts to provide for mutual exclusion. 

£f. Eventcounts 

"Eventcounts”" are used in this implementation to 
allow processes to arbitrate access to shared resources. An 
eventcount is defined by Reed [10] as: "An eventcount is an 
object in the system that represents a class of events that 
will eventually occur". Each eventcount represents a distinct 
Class of events. This class of events is ordered so that by 
the time event N occurs all events numbered from 0 to N-1 will 
have occurred. Consequently, the set of events that have 
occurred at any particular time can be represented by the 
number of the last event to occur. This number is known as 


the "current value" of the eventcount. 
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An eventcount is associated with some type of event 
of interest, e.g., occurrence of a real-time interrupt, a data 
Segment being read or written into, etc. Eventcounts are 
implemented as sets of positive integers from 0 to infinity 
(the current limit in this implementation is actually 65,536 
using PL/M-86 "word" variables which is "adequate" for the 
applications anticipated) and are used to keep track of the 
total number of such events that have occurred. 

The eventcount synchronization mechanism has the 
useful property that two virtual processors waiting for events 
in the same class (thus recorded in the same eventcount) do 
not have an inherent intercommunication path. The enabling of 
one virtual processor to proceed does not automatically disable 
any other virtual processors from proceeding and allows 
broadcasting events to multiple virtual processors. This is 
a function not easily achieved uSing semaphores. Consequently, 
this mechanism is more desirable for use in a secure system to 
address the "confinement property". Further, the implementa- 
tion of eventcounts is not inherently more difficult than 
that of semaphores. 

There are three operations which may be performed 
on eventcounts, as follows: 

(1) "Read" Operation. The current value of an 
eventcount may be obtained by the READ operation. This oper- 


ation returns the present value of the eventcount as a "positive 
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integer" n. From this value, one may infer that events 0 ton 
have already occurred. TCSREAD (Traffic Controller RFAD) in 
the present implementation is a function call in the Traffic 
Controller Level available ("visible") to the user via the 
"GATE" so that it will provide him the capability to obtain, 
the current value of the eventcount of interest specified 

in the call. Details will be discussed in the corresponding 
module of the Traffic Controller later in this chapter. 

(2) "AWAIT" Operation. Allows the calling subject 
to await a particular event in the class associated with the 
eventcount. This operation requires that the event name and 
the awaited eventcount value be specified. Particularly in 
the present implementation there are two procedures as follows: 

TCSAWAIT ( Traffic Controller AWAIT) is an 
inter-process synchronization primitive. Allows a process (the 
"calling" process) to suspend its own execution (enter the 
"blocked" state) until the event specified in the input argu- 
ment (by name and value) has occurred, viz., the eventcount 
reaches the specified awaited value. The result is that the 
process will "give away" the virtual processor to which it is 
bound. The effect of this operation is similar as the conven- 
tional Saltzer's "Block" operation or Dijkstra's "P" operator 
(On counting semaphores). 

TCSAWAIT is a procedure in the Traffic 
Controller Level "visible" to the user via the "GATE". Details 
will be discussed in the corresponding module of the Traffic 
Bentroller later in this chapter. 
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[tess taner Traffic Controller AWAIT), is 
an inter-virtual processor synchronization primitive. It 
suspends the execution of the "running" virtual processor 
(setting its state to "waiting") until the event specified 
(by name and value) in the input argument has occurred, viz., 
the eventcount reaches the specified awaited value. This 
Synchronization primitive is used by the Inner Traffic 
Controller for the management of system resources. ITCSAWAIT, 1s 
"invisible" to the user, and is used only by the operating 
system. Details will be discussed in the corresponding module 
Se tcne ITC later in this chapter. 

TCSAWAIT/ITCSAWAIT will prevent the process/ 
Virtual processor respectively from proceeding until the 
current value of the eventcount reaches the awaited event 
value specified in the procedure's call. 

(3) "ADVANCE" Operation. This operation informs 
the processor multiplexing mechanism of the new value of the 
advanced eventcount and requires that the event name be 
specified as an argument. Particularly in this implementation 
there are two procedures as follows: 

TCSADVANCE (Traffic Controller ADVANCE) is an 
inter-process synchronization primitive. A TCSADVANCE opera- 
tion is performed by a process when an event has occurred. It 
increments the current value of the specified eventcount by 
One to reflect the occurrence of the event. This has the 


effect of signalling the event's occurrence to other processes 
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Whach were waiting for it by virtue of having previously per- 
formed an AWAIT operation on that event. The effect of an 
ADVANCE operation is essentially the same as a Saltzer's 
Wakeup operation of Dijkstra's "V" operator (on counting 
semaphores). 

The eventcount signalling mechanism has an 
"automatic broadcast effect" which offers an advantage in 
parallel processing. This broadcast capability allows the 
"simultaneous signalling" of several processes which otherwise 
would have to be signalled "sequentially". 

TCSADVANCE is a procedure in the Traffic 
Controller Level "visible" to the user via the "GATE". 
TCSADVANCE is also in this implementation responsible for 
the "preemptive scheduling". Details will be discussed in 
the corresponding module of the Traffic Controller later in 
this chapter. 

ITCSADVANCE (Inner Traffic Controller 
ADVANCE), is an inter-virtual processor synchronization 
primitive. Signals that the specified in the call event 
(event's name is the input argument) has occurred by advanc- 
ing (incrementing by one) the value of the associated 
eventcount. This eventcount signalling mechanism has also 
an "automatic broadcast" effect which offers an advantage in 
parallel processing. All the virtual processors awaiting 
the occurrence of this specific event are informed. 


ITCSADVANCE is a procedure in the Inner Traffic Controller 


2:1. 





Level "invisible" to the user and is used only by the opera- 
ting system for the management of system's resources. 
Details will be discussed in the corresponding module of the 
mre later in this chapter. 

to) Sequencers 

There are many situations where accesses to 
Shared resources must be totally ordered. Eventcounts alone 
are not sufficient to accomplish this. To provide the 
Capability for mutual exclusion, another type of object 
called a "Sequencer" [10] is employed. A sequencer is 
implemented as a positive integer ranging in value from 0 to 
Maeinity (as with eventcounts, the current limit in this 
implementation is 65,536). However, a sequencer is used to 
provide total order to the occurrence of events. 

A sequencer is also necessary to solve the 
confinement and readers/writers problems. Some synchroniza- 
tion problems require arbitration, e.g., two write accesses 
to the same segment. Eventcounts alone as already discussed 
do not have the ability to discriminate between two events 
that happen in an uncontrolled (i.e., concurrent) manner. 

Initially a sequencer has a value of 0. The value 
increases by one each time a "TICKET" operation is performed 
on it. TICKET is the only operation defined on a sequencer. 
TICKET returns a unique monotonically increasing value with 
each call. It is similar to getting a ticket and waiting to 


be served at a restaurant. Two uses of TICKET will return 
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two different values corresponding to the "relative time" of 
call. Thus, a set of events can be totally ordered by using 
the TICKET operation. Details about TICKET operation will be 
discussed in the corresponding module of the TC later in this 


chapter. 


fee ANIL ERRUPT STRUCTURE 
ieeeentsoduction 

The operating system has to control a multiple- 
processor environment. This generates the need of some method 
of communication between physical processors. This need is 
satisfied by an ability to generate hardware interrupts 
between the physical processors. The interrupts are used 
for the implementation of "preemptive scheduling". INTEL's 
8086 microprocessor, aS most microprocessors, doesn't possess 
the capability to directly generate interrupts destined for 
Other devices (the devices of interest here are other 
processors). We provide that capability by suitably configur- 
ing the hardware and using some software control. Note that 
only a "single" interrupt line is actually used to implement 
System-wide preempt interrupts. This is the only hardware 
configuration adaptation to facilitate the operating system 
and we are going to describe it in detail. 

The system's interrupt structure is managed by the 
Inner Traffic Controller. In particular, a physical system 


interrupt is transformed into a synchronization signal to a 
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weaetang virtual prccessor. This structure is particularly 
important for the support of real-time processing and note 
that this is completely distinct from inter-process synchro- 
nization and communication. 

To implement this desired configuration we use the 
8259A PIC (Programmable Interrupt Controller) and 8255A PPI 
(Programmable Peripheral Interface), both on board on the 
86/12A microcomputer. 

The 8086 instructions support two types of interrupts, 
external and internal (or "trap"). An external interrupt is 
initiated by some peripheral asserting an interrupt request 
to the 8086 in the hardware. An internal interrupt is one 
initiated by the software the 8086 is executing. An inter- 
rupt represents a transfer of program execution control. The 
type of transfer used in the 8086 is called a vectored 
interrupt. An interrupt vector represents an address of a 
procedure which services the interrupt. 

In the 8086 all interrupts (both external and 
internal) perform a transfer by pushing the flag registers 
onto the stack (as in PUSHF), and then performing an indirect 
call (of the intersegment variety) through an element of an 
interrupt vector located at absolute memory locations 0 through 
3FFH. Each vector is a four byte element with the first two 
bytes containing the offset of a procedure (or label) and the 
second two bytes containing the paragraph number of the 


segment containing the procedure (or label). There are 256 
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possible interrupt vectors. Within the 8086 assembly 
language, each vector is given a number from 0 through 255. 
Interrupts 0 through 4 (0-13H) currently have the dedicated 
hardware functions as defined on Figure 29 below (the dedica- 


tion has been made by INTEL Corporation). 


Interrupt # Location Ee blgkex eateya| 
0 0-03H divide by zero 
i O04H-07H Single step 
J O8H-OBH non-maskable interrupt 
3 OCH-0FH one byte interrupt 


instruction (INT 3) 


4 LOH-13H interrupt on overflow 


BEGURE 29. INTERRUPTS 0 to 4. 


There are three interrupt transfer operations provided: 

- INT pushes the flag registers, clears the TF (Trap Flaq) 
and IF (Interrupt Flag) flags, and transfers control 
with an indirect call through any of the 256 vector 
elements, 1.e., INT 24 will do an indirect call 
through interrupt vector 24 (location 96). A one byte 
form of this instruction is available for interrupt 
type 3, INT 3. We use INT instruction for the 
implementation of the "GATE". 

- INTO pushes the flag registers, clears the TF and IF 


Flags and transfers control through vector element 4 
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PemenewOr Flagets set (interrupt on overflow). If 

the OF flag is cleared, then no operation takes place. 
- ITRET transfers control to the return address saved by 

a previous interrupt operation and restores the saved 

flag registers. This instruction is used several 


times for the implementation of the operating system. 


For external interrupts, the peripheral device will request 
an interrupt from the 8086. When the 8086 grants the inter- 
rupt, the device will supply a byte value on the data bus 
which represents the type or number of the interrupt i.e., 
0 through 255. The 8086 will read this value and then 
execute the interrupt through the vector. 
eeeeehardware Interrupts 

The 8086 CPU includes two hardware interrupt inputs, 
NMI and INTR, classified as non-maskable and maskable, 
respectively. 

a. Non-Maskable Interrupt (NMI) 

The NIM input has the higher priority of the two 
interrupt inputs. A low-to-high transition on the NMI input 
will be serviced at the end of the current instruction or 
between whole moves of a block-type instruction. Worst-case 
response to NMJ is during a multiply, divide, or variable 
Bmitt instruction. 

When the NMI input goes active, the CPU performs 


the following: 
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(1) Pushes the Flag registers onto the stack 
(same as a PUSHF instruction). 


(2) If not already clear, clears the Interrupt 
Flag (same as a CLI instruction). This 
disables maskable interrupts. 


(3) Transfers control with an indirect call 
through vector location 00008. 


The NMI input is intended only for catastrophic 
error handling such as a system power failure. Upon 
completion of the service routine, the CPU automatically 
restores the flags and returns to the main program. 

b. Maskable Interrupt (INTR) 

The INTR input has the lower priority of the two 
interrupt inputs. A high level on the INTR input will be 
serviced at the end of the current instruction or at the end 
of the whole move for a block-type instruction. 

When INTR goes active, the CPU performs the 
Following (assuming the Interrupt Flag is set): 

(1) Issues two acknowledge signals. Upon receipt 
of the second acknowledge signal, the 
interrupting device (master or slave PIC) 
will respond with a one-byte interrupt 


identifier. 


(2) Pushes the Flag registers onto the stack 
(Same as a PUSHF instruction). 


(3) Clears the Interrupt Flag thereby disabling 
further maskable interrupts. 


(4) Multiplies by four (4) the binary value (X) 
contained in the one-byte identifier from 
the interrupting device. 


(5) Transfers control with an indirect call 
through location 4X. 
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Upon completion of the service routine, the CPU 
automatically restores its flags and returns to the main 
program. 

in 25 oe LOmmeronmanmmable Internsnupt Controller) 

The on board 8259A PIC functions as an overall 
manager in an interrupt-driven system environment. It accepts 
requests from the peripheral equipment, determines which of 
the incoming requests is of the highest importance (priority), 
ascertains whether the incoming request has a higher priority 
value than the level currently being serviced and may issue 
an interrupt to the CPU based on this determination. 

The on board master 8259A PIC handles up to eight 
vectored priority interrupts and has the capability of 
expanding the number of priority interrupts by cascading 
one or more of its interrupt input lines with slave 8259A 
PIC's. Note that slave PIC's are not used in this 
implementation. 

The basic functions of the PIC are to (1) resolve the 
priority of interrupt requests, (2) issue a single interrupt 
request to the CPU based on that priority, and (3) send the 
CPU a vectored restart address for servicing the interrupting 
device. 

a. Interrupt Priority Modes 

The PIC can be programmed to operate in one of 


the following modes: 
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(1) Nested Mode 

(2) Fully Nested Mode 

(3) Automatic Rotating Mode 

(4) Specific Rotating Mode 

(5) Special Mask Mode 

(6) Poll Mode 

In this design the Nested Mode is used and is 
described in the next paragraph. 

b. Nested Mode 

In this mode the PIC input signals are assigned 
a priority from 0 through 7. The PIC operates in this mode 
unless specifically programmed otherwise. Interrupt IRO has 
the highest priority and IR7 has the lowest priority. When 
an interrupt is acknowledged, the highest priority request 
1s available to the CPU. Lower priority interrupts are 
inhibited, higher priority interrupts will be able to 
generate an interrupt that will be acknowledged, if the CPU 
has enabled its own interrupt input through software. The 
End-Of-Interrupt (EOI) command from the CPU is required to 
reset the PIC for the next interrupt. 

Details for the remaining modes are described in 
Reference [2]. 

c. Status Read 
Interrupt request inputs are handled by the 


Following three internal PIC registers: 
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(2) 


(2) 


(3) 


Interrupt Request Register (IRR) which 
stores all interrupt levels that are 
requesting service. 


In-Service Register (ISR) which stores all 
interrupt levels that are being serviced. 


Interrupt Mask Register (IMR) which stores 
the interrupt request lines which are masked. 


These registers can be read by writing a suitable 


command word and then performing a read operation. 


ad. Initialization Command Words 


The on board master PIC and each slave PIC 


requires a separate initialization sequence to work in a 


particular mode. 


The initialization sequence requires three 


Initialization Command Words (ICW's) for a signle PIC system 


and requires four ICW's for a master PIC with one to eight 


Slaves. The ICW formats are shown in Figure 30. Since no 


Slave PIC's are used we shall describe below only the 


initialization command words needed to initialize the 


Sm board PIC. 


The First Initialization Command Word (ICWl), 


which is required in all modes of operation consits of the 


followina: 


(1) 


Bits 0 and 4 are both 1's and identify the 
word as ICWl for an 8086 CPU operation. 


Bit 1 denotes whether or not the PIC is 
employed in a multiple PIC configuration. 
For a Single master PIC configuration 

(no slaves) bit 1l=1; for a master with 
one or more slaves bit 1=0. Note that 
bit 1=0 only when programming a slave PIC. 
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(3) Bit 3 establishes whether the interrupts 
are requested by a positive-true level input 
or requested by a low-to-high input. This 
applies to all input requests handled by 
In other words, 
low-to-high transition is required to request 
an interrupt on any of the eight levels 
handled by the PIC. 


the PIC. 


1f bit 3=l, a 


The second Initialization Command Word (ICW2) 


represents the vectoring byte (identifier) and is required 


by the 8086 CPU during interrupt processing. 


of the following: 


ICW2 consists 


(1) Bits D3-D7 (Al11-Al5) represent the five most 
Significant bits of the vector byte. These 


are supplied by the programmer. 


(2) Bits DO-D2 represent the interrupt level 
requesting service. 
by the 8259A during interrupt processing. 
These bits should be programmed as 0's when 
fiitiralsezemg the PEC. 


These bits are provided 


Note that the 8086 CPU multiplies the vector byte 


by four. This value is then used by the CPU as the vector 


address. 


interrupts IRO-IR7. 
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It is important here to notice that the monitor 
of each microcomputer [21] initializes the PIC. For testing 
this hardware configuration the interrupt line 4 is connected 
and the interrupt vector byte (of Figure 31) is initialized 
(just for this kernel program) to 40H. Note that the three 
LSB bits (DO, Dl, D2) are always initialized to 0. For the 
specific initialization, bit D6=l and all the rest are 0. 
Since the interrupt line 4 is connected, the PIC upon 
receiving an interrupt resolves the priority and sets the 
bits D2=1, D1l=0, DO=0 (D2D1D0=100=4). Therefore, the 
interrupt vector byte is set to 40H+4=44H. The 8086 CPU 
multiplies the interrupt vector byte by 4 and the resulting 
value, 110H, is the vector address. The CPU will transfer 
control to this address to execute the interrupt service 
routine corresponding to the interrupt 4. A pointer (four 
bytes) pointing to the starting point of the interrupt 
service routine must be located in the physical absolute 
address (110H) corresponding to the received interrupt. 

Since both the monitor and the kernel initialize 
the PIC there exists a probability of conflict as follows: 
If the first 100 bytes of local RAM memory of every micro- 
computer will be displayed using the monitor's display 
command, as in Figure 32, then we can see that the monitor 
uses 12 bytes (04 to OF). Also 32 bytes are occupied 
(80H to 9FH) and these are pointers to a single entry point 


(pointer 6C 06 00 FE is repeated 8 times). If the interrupt 
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vector address, after the PIC initialization, happens to be 
between 80H and 9FH the interrupt service routine pointer 

is overwritten by the monitor. The solution is to substitute 
(using monitors' "S" command) the service routine vector in 
place of the monitor's interrupt service routine vector. For 
example if we initialize the interrupt vector byte of Figure 
31 with 20H and use interrupt line 4, then after CPU's 
multiplication by 4, the resulting vector address is 24H*4=90H. 
Before execution we have to substitute the four bytes 90H to 
93H with the interrupt service routine pointer. 

If we avoid the area (from 80H to 9FH) then there 
1S no problem. Also when the operating system (instead of 
the monitor) will be the permanent resident of ROM, this 
problem will not exist. (See also Anderson's thesis [19]). 

Now the PIC initialization is continued. 

The third initialization command word, ICW3, is 
not required for this implementation since we do not use 
Slave PIC's. 

The fourth Initialization Command Word (ICcW4), 
which is required for all modes of operation, consists of 
the following: 


(1) Bit DO is alto identify that the word is 
forvan 8086 CPU. 


(2) Bit Dl (AEOI) programs the end-of~interrupt 
function. Code bit 1=1 if an EOI is to be 
automatically executed (hardware). Code 
Bit 1=0 if an EOI command is to be generated 
by software before returning from the ser- 
vice routine. 
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(3) Bit D2 (M/S) specifies if ICW4 is addressed 
to a master PIC or a slave PIC. For example, 
code bit 2=1 in ICW4 for the master PIC. 
fie eree mS. (BUF) is zero, bit D2 has no 
1s bake sWongrs 


(4) Bit D3 (BUF) specifies whether the 8259A is 
operating in the buffered or nonbuffered mode. 
For example, code bit 3=1l1 for buffered mode. 
The master PIC in an iSBC 86/12A, with or 
without slaves, must be operated in the 
buffered mode. 


(5) Bit D4 (FNM) programs the nested or fully 
nested mode. 


In summary, three ICW's are required to initialize 

the on board PIC in this implementation, ICWl, ICW2 and ICW4. 
e. Operation Command Words 

After being initialized, the master and slave 
PIC's can be programmed at any time for various operating 
modes. The Operation Command Word (OCW) formats are shown 
in Figure3-15 of Reference [2]. The format of the only one 
operation command word used in this implementation (OCWl) 1s 


shown in Figure 33. 
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FIGURE 33. OPERATION COMMAND WORD #1, (OCW 1) 
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f. Addressing 
The master PIC uses Port 00C0O or 00C2 to write 
initialization and operation command words and Port 00C4 or 
00C6 to read status, poll and mask bytes. Addresses for the 
specific functions are provided in Reference [2]. 
g. Initialization 
To initialize the PIC the following steps must 
be followed: 


1. Disable system interrupts by executing a CLI 
(Clear Interrupt Flag) instruction. 


2. Initialize master PIC by writing ICW's in 
the following sequence: 


Write ICWl to Port 00CO and ICW2 to 
Porte OO0CZ2. 


Wage ews to Porte 00E2, 


3. Enable system interrupts by executing an 
STI (Set Interrupt Flag) instruction. 


h. Operation 
After initialization, the master PIC and slave 
PIC's can independently be programmed at any time by an 
Operation Command Word (OCW) for the following operations: 
(1) Auto-rotating priority. 
(2) SSpectites rotating)» priority. 


(3) Status read of Interrupt Request Register 
(IRR). 


(4) Status read of In-Service Register (ISR). 
(5) Interrupt mask bits are set, reset, or read. 


(6) Special mask mode set or reset. 


PS 7 





The details of these Operation Command Words are 
described in Reference [2]. In this implementation, only the 
OCWl is used which has already been described. 

4. 8255A PPI (Programmable Peripheral Interface) 

The three parallel I/O ports interfaced to connector 
Jl of the 86/12A microcomputer are controlled by an INTEL 
8255 Programmable Peripheral Interface chip. Port A includes 
bidirectional data buffers and Ports B and C include IC 
sockets for installation of either input terminators or out- 
put drivers depending on the user's application. 

Default jumpers set the Port A bidirectional data 
buffers to the output mode. Optional jumpers allow the 
bidirectional data buffers to be set to the input mode or 
allow any one of the eight Port C bits to selectively set 
the Port A bidirectional data buffers to the input or output 
mode. 

Reference [2] lists the various operating modes for the 
three PPI parallel I/O ports. Note that Port A (00C8) can 
be operated in Modes 0, 1, or 2; Port B (Q0OCA) can be 
Operated in Mode 0 or 1; Port C (00CC) can be operated in 
Mode 0. 

Pee Conc rel Word, Format 

The control word format shown in Figure 34 is 
used to initialize the PPI in order to define the operating 
mode of the three ports. Note that the ports are separated 


into two groups. Group A (control word bits 3 through 6) 


138 





defines the operating mode for Port A (00C8) and the upper 
Meme Dits Of Port C (00CC). Group B (control word bits 0 
through 2) defines the operating mode for Port B (00CA) and 
mm@emlower four bits of Port C (00CC). Bit 7 of the control 
word controls the mode set flag. 
b. Addressing 
The PPI uses four consecutive even addresses 
(00C8 through OOCE) for data transfer, obtaining the status 
mmecontrol of the PPI at Port C (00CC). 
en Enitialization 
To initialize the PPI, a control word is written 
to the port address QOOCE. In Figure 34, an example is given 
for the PPI initialization. In this example, the control 
word is 92H. This initializes the PPI as follows: 
(1) Mode Set Flag active 
(2) Port A (00C8) set to Mode O Input 
(3) Port C (00CC) upper set to Mode 0 Output 
(4) Port B (00CA) set to Mode O Input 
(5) Port C (00CC) lower set to Mode O Output 
d. Operation 
After the PPI has been initialized, the operation 
is completed by simply performing a read or a write to the 
appropriate port. 
Pee owne Accual Configuration 
a. Hardware Connections 
The hardware connections to implement this hardware 


adaptation are marked with special comments in the following 
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CONTROL WORD 


ica ed ce eB 


GROUP B 


PORT C (LOWER) 
1 = INPUT 
QO = OUTPUT 


MODE SELECTION 
QO = MODE 0 
1 = MODE 1 


GROUP A 


Pont  @ (UPPER) 
1 = INPUT 

QO = OUTPUT 
PORT A 

1 = INPUT 

QO = OUTPUT 
MODE SELECTION 
00 MODE 0 

Ol MODE lL 

1X MODE 2 


MODE SET FLAG 
1 = ACTIVE 





FIGURE 34. PPI CONTROL WORD FORMAT 
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Figures 36 and 37. In Figure 36 (This is the Figure 5-2, sheet 
Seer il, of Reference [{2]) pin EY is connected with pin E14. 
fits Connection will connect PC7 (bit 7, e.g., the MSB of Port 
"C") to the BUS INTR OUT. Port "C" and BUS INTR OUT line are 
Shown on Figure 35. 

In Figure 37, (This is the Figure 5-2, sheet 8 of 
ll of Reference [2]) pin E137 is connected with pin E142. This 
connection will connect INTR 4 (interrupt 4 line) to the BUS 
INTR OUT. Then pin E69 is connected with pin E77. This 
connection will connect BUS INTR OUT to the IR4 (interrupt 4) 
input of the 8259A PIC (Programmable Interrupt Controller), via 
the Interrupt Matrix. INTR4, IR4 and Interrupt Matrix are 
shown i Hagqure 35. 

With the above three jumpers, we connected the MSB 
(bit 7) of Port "C" (of 8255A Programmable Peripheral Interface) 
with IR4 (interrupt 4 input of the 8259A PIC). These connec- 
tions have to be made on every 86/12A microcomputer in the 
system. 

We have to note here that interrupt line 4 is 
selected arbitrarily. It is possible to connect a different 
line or to connect parallel Port "A" or "B". We selected 
"C" in order not to interfere with the operations of the 
data ports "A" and "B". 

b. Software Control 
In order to receive an interrupt the 8259A PIC has 


to detect a "Low to High" transition in the corresponding input 
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(IR 4 in our case). Since we already have connected PC7 (MSB 
of Port "C") with the interrupt line 4, we only need to "Reset- 
Set" that MSB by writing a byte into the Parallel 

Port "C" (specifically to port address "00CC"). 

Sm@eette Pome C' 1S an eight bit port, to reset 
the MSB (PC7) we can write to Port "O00CC" any number from 0 to 
79H (MSB equal 0). To set the MSB we can write any number 
from 80H to OFFH (MSB equal 1). 

We also use a "global" array of flags, called in 
the implementation HDWSINTSFLAG (Hardware Interrupt Flag). 
HDWSINTSFLAG (n) corresponds to the processor whose identifica- 
tion number (CPUSNUMBER) equals n. Since this flag array is 
global, each physical processor can access the flag of any 
other processor in the system. 

This way we establish an effective and simple 
design and implementation of the "inter-physical processor 
communication" using just "one" hardware interrupt line. The 
algorithm is shown in Figure 38. When a processor #n needs 
to preempt another processor #m, then it first set its 
corresponding flag, e.g., HDWSINTSFLAG(m) = TRUE and after- 
wards sends a hardware interrupt by writing to Port address 
"00CC" first a zero, then an 80H and finally a zero. This 
way processor #n generates the "Low to High" transition at 
the interrupt 4 input (IR 4) of the 8259A PIC of "every" 
86/12A microcomputer (including itself) in the system. Then 
every processor jumps to the interrupt handler that first 
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WHEN PROCESSOR #n NEEDS TO PREEMPT PROCESSOR #m 


SETS HDWSINTSFLAG(m) = TRUE 





SENDS ACTUALLY A HARDWARE INTERRUPT AS FOLLOWS: 


OUTPUT (PORTSOOCC) RESET A "LOW TO HIGH" 
TRANSITION FOR IR4 


OUTPUT (PORTSOOCC) SET (TRIGGERED MODE IS USED) 
OUTPUT (PORTSOOCC) RESET | 


EACH ONE PROCESSOR JUMPS TO THE INTERRUPT HANDLER AND 
ASKS ITSELF THE QUESTION: 





IF "9 YES 9 LF "NO a 





SAVES EXECUTION POINT 
OF PREVIOUS TASK. 

2. RESETS ITS OWN FLAG. 

Sa CONTINUES ON THE 

ENTERRUPT SERVICE 

ROUTINE. 





CONTINUES ON 






ERE VEOUS TASK 








FIGURE 38. PREEMPTIVE HARDWARE INTERRUPT ALGORITHM 
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checks its own HDWSINTSFLAG. If the flag is not set, the 
processor continues on the previous task by using the IRET 
instruction. Otherwise, if the interrupt was destined for 
it, this processor saves the execution point of the previous 
task, resets its HDWSINTSFLAG and then continues on the 


interrupt service routine. 


H. SYSTEM-WIDE DATABASES 
The operating system is "database" or "control table" 
driven. There are several shared databases (shared segments) 
that reside in the global memory where any processor can 
access them to maintain and update the shared control data 
used by the operating system. 
1. Virtual Processor Map (VPM) 
The Inner Traffic Controller is the physical resource 
manager. The VPM is the principal global data base that 
Maintains and updates the data used by the ITC to multiplex 
virtual processors among real processors and to create the 
extended instruction set that controls the virtual processor 
Operation. The VPM is a system wide database and is kept in 
global memory (as a shared segment) to facilitate inter- 
virtual processor communication and synchronization. 

Each physical processor has its own fixed set of 
virtual processors (four in the current implementation) used 
in multiplexing. See Figure 39. The first and fourth VP 
(VPSSTART and VPSEND) are invisible to the TC level (invisible 


to the user processes) and are permanently bound to the memory 
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£T+1 #7T+2 #K=I+3 
(K=VPS EN1) 
Le 
MACHINE 


REAL 


PROCESSOR 
| #n 





n = CPUSNUMBER = LOGSCPUSNUMBER 


FIGURE 39. EACH REAL PROCESSOR POSSESSES FOUR VIRTUAL PROCESSORS 
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management process and idle process respectively. The VPSSTART 
has the highest priority (0 in this implementation) and the 
VPSEND the lowest (255 or FFH). The remaining two have 
priority equal to the priority of the user processes bound 

to them. In this way the ITC recognizes that each real 
processor possesses four VP while the TC recognizes only 

two VP per real processor. A virtual processor mapping 

among the TC and ITC is needed to support this different VP 
view. 

It 1S important to understand that this VP multi- 
plexing among physical processors is an economic way for using 
the physical processor and physical resources in general. For 
example, by binding permanently the MMGT (Memory Management 
process) to a VP and assigning to this VP (VPSSTART) the 
highest priority, the MMGT process will occupy (run on) 
the physical processor each time there is reason (e.g., when 
some system event happens that requires a response by the 
MMGT). Otherwise another VP runs on this physical processor 
either the idle process or a user process. On the other 
hand if a real processor was permanently bound to the MMGT 
process, this physical resource would be idle whenever the 
MMGT process has nothing to do. 

It is also important to note that the ITC 
executing on a physical processor is primarily concerned 
only with its set of the four VP. However, the performance 
of system-wide synchronization requires access to the remaining 
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virtual processors as well, so that signals may be used to 
alert other physical processors (we have discussed already 
the case of preemptive scheduling). This is accomplished by 
maintaining the Virtual Processor Map as a shared data base 
containing entries for all of the virtual processors in the 
system. Making it globally available facilitates communica- 
tion between virtual processors on a system-wide scale. The 
Virtual Processor Map fields are shown in Figure 40. 

The VPM INDEX starts from 0 to the value NRSRPS 
* VPSSPERSCPU-1], viz., number of real processors in the 
system multiplied by the number of virtual processors per real 
processor (four in current implementation) minus 1. This VPM 
INDEX represents a whole entry into VPM (a horizontal line in 
Figure 40). For example, VPM(0) represents the first entry 
(horizontal line), VPM(1) the second and so on. 

The VPSID field is used to support the VP mapping 
between the TC and ITC. Details will be discussed in para- 
graph I8 of this chapter.. 

The VPSSTATE (virtual processor state) field 
reflects the present state of the virtual processor and can 
be any of "ready", "running", "waiting", or "idle". A ready 
virtual processor is bound to a process and is in "contention" 
for the physical processor. The running virtual processor is 
that virtual processor which is actually executing a process 
on this physical processor. The waiting state reflects 


physical resource management. The idle state is assumed by 
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a virtual processor which has no process bound to it. The 
idle state prevents the assignment of useless (idle) work to 
a phySical processor. Figure 8 illustrates the state transi- 
tions made by the virtual processors. In paragraph C7b of 
Chapter II the possible transitions of state for a VP are 
described. 

The VPSPRIORITY (virtual processor priority) field 
of the virtual processor is used in scheduling. The highest 
priority runnable virtual processor is selected to run. This 
priority is determined by the priority of the process bound to 
the virtual processor. The VPSSTART, which is permanently 
bound to the MMGT process has the highest priority (zero) and 
the VPSSEND the lowest priority (255 or FFH). 

The EVCSAWSID (Awaited Eventcount Identifier) and 
EVCSAWSVALUE (Eventcount's waited value) fields are used in 
Inter-virtual processor communication and synchronization. 
Details will be discussed in the ITCSAWAIT and ITCSADVANCE 
modules of the ITC later on in this chapter. 

The SSSREG (Stack Segment Register Value) field 
defines the address space of the process bound to this VP. 

It holds the "process address space descriptor" (analogous to 
DBR in MULTICS). The execution point of the process is stored 
on the stack when the process is not actually running. This 
SSSREG is the only value which is required to access the 
address space of the process, viz., it is changed to swap 


processes. 
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The PESPEND (Preempt Pending Flag) field is used 
for preemptive scheduling. It serves to transform a hardware 
interrupt sent to the physical process into a virtual preempt 
interrupt. 

2. Active Process Table (APT) 

The Traffic Controller multiplexes user (or applica- 
tion) processes among virtual processors. In this way the TC 
is responsible to manage the execution of user processes 
("processes management"). It is noted, one more time, that 
Since the processes are assigned to virtual processors (and 
not real processors), there is no effect on the user when 
real processors are added or deleted in the system, except, 
of course, for the change in performance. Most of the 
design and implementation, presented to the user, are inde- 
pendent of the physical configuration of the system. 

The Traffic Controller's principal global data base 
is the Active Process Table (APT), shown in Figure 41. The 
entry for each process in the Active Process Table contains 
sufficient information about the process to enable a virtual 
processor to be bound to and execute it. 

The APT INDEX starts from zero and grows as far as 


processes are loaded in the system. For example, the APT(0) 


represents the first entry (horizontal line) in the APT, APT(1) 


Ehe second and so on. 
The STATE field represents the state of a process and 


mecan be either “ready”, “running", or "blocked". A ready 
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process is one which is not yet bound to a virtual processor 
mie 2S ready to do so (it is in "contention" for VP). A 
running process is one which is bound to a virtual processor 
and, as far as the process 1S concerned, executing. The 
blocked state reflects inter-process synchronization. A pro- 
cess enters the blocked state when it realizes that it can no 
longer proceed and wishes to "give up" its virtual processor 
to wait until another process awakens it. This is important 
for the economic advantage of virtual processor multiplexing 
algorithm, viz., a process which can no longer run, waiting 
for the occurrence of an event frees the virtual processor 
which was bound to this process. The possible states of a 
process and the transitions among them are shown in Figure 7 
and explained in paragraph C7a of Chapter ITI. 

The AFFINITY field specifies the physical processor 
on which the process is currently loaded. It is possible to 
change this field during system "reconfiguration", Anderson 
[19]. 

‘The VPSID (Identity Of Bound Virtual Processor) field 
serves to identify the virtual processor, if any, that the 
process is currently bound to. It is noted that the user 
processes are multiplexed among the two central virtual pro- 
cessors of each real processor as shown in Figure 39. The VP 
with identification number VPSSTART and VPSEND are invisible 
to the TC and the user. The necessary mapping among VPSID of 
the ITC and TC will be discussed in the ITCSRETSVPTC module 


in paragraph I8 in this Chapter. 
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MReSPRIORITY £2eld specifies the priority of the process. 
In this system, priorities range in value from 0 to 255, with a 
priority of 0 being the highest. When a process is bound to a 
VP, the VPSPRIORITY field of the VPM corresponding to this 
specific VP, becomes equal to the PRIORITY field of the process. 

The LOADSTHREAD (Loaded List Thread) field serves to 
implement the "Loaded List" of the ready, running and blocked 
processes. It contains a pointer to the next process in the 
Active Process Table which is loaded on the same microcomputer 
as this process. The meaning of this statement is that the 
“loaded list", which is a "linked list", is kept updated "per 
physical processor". A loaded process has its address 
Space in primary storage; therefore it may be scheduled 
to run on a VP. In general, a process can be loaded on 
only a single physical processor at a time, due to the 
use of processor-local memory. The loaded list is ordered 
(sorted) by the priorities of the processes. Thus this 
field contains either a pointer to a process whose priority 
is less than or equal to that of this process or a nil 
pointer (viz., the last process on this Loaded List). 

The EVCSVALUESAW (Value of Eventcount Awaited) field 
reflects the event for which the process has blocked itself. 
It contains the value that the process is waiting for the 
eventcount to reach. When this specific eventcount reaches 
this value the process will awaken and its state will change 
from "blocked" to "ready". The usefulness of this field will 
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be better understood when describing the TCSAWAIT and TCSADVANCE 
modules. 

The THREAD (Block List Thread) field is used to imple- 
ment the Blocked List. This is a "per eventcount" linked list 
of processes which are waiting on the same eventcount. 

The DBR (Address Space Descriptor) field contains the 
process' address space descriptor. This is the identity of the 
process' stack which contains execution point information. The 
value used here is the base location in memory of the stack 
segment, viz., the Stack Segment (SS) Register value. This 
field is implemented exactly the same way as the SSSREG field 
of the VPM. 

Above we described that the LOADSTHREAD field is used 
to implement a "per physical processor" linked list (the "load 
list") of the ready, running, and blocked processes and also 
that the THREAD field is used to implement a "per eventcount" 
linked list of the blocked processes waiting this eventcount. 
For better understanding of these statements we shall use an 
example later on, in paragraph H6. 

3. Eventcount Table (EVCSTABLE) 

The Eventcount Table is also a global data base for 
the TC level, as shown in Figure 42 and is used by the 
inter-process synchronization mechanism. 

The EVCSTABLE INDEX starts from zero and grows as 


new events are added in the system by calls from the 
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application processes. For example, the EVCSTABLE(0) 
represents the first entry (horizontal line) in the EVCSTABLE, 


EVCSTABLE(1) the second and so on. 
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FIGURE 42. EVCSTABLE (EVENTCOUNT TABLE) 


The EVCSNAME (eventcount name) field is a character 
array of six letters. The first five letters is the name given 
to the specific event by the user and the last letter is a 
delimiter (% is used). This name is used as the input argument 
of the TCSAWAIT and TCSADVANCE operations. 

The EVCSVALUE (Eventcount value) field holds the 
current value of the eventcount. Each time a TCSADVANCE oper- 
ation is executed, this value is incremented by one. Each time 
the TCSAWAIT or TCSADVANCE is invoked, a comparison is made 


between this Eventcount current value and the awaited value to 
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decide if the state of the process will remain blocked or 
will be changed to ready. 

The APTSPTR (Active Process Table Pointer) field is 
a pointer which points to the first member of the blocked 
list (the “per eventcount" link list discussed in previous 
paragraph) corresponding to this specific eventcount. The 
usefulness of this pointer will be better understood in the 
example promised in previous paragraph. 

This structure also uses the variable EVENTS with 
initial value zero. The value of EVENTS is incremented by 
One each time the TCSCREATESEVC (Traffic Controller Create 
Eventcount) is invoked by an application process. [In this 
way the operating system keeps track how many events are 
currently in use for inter-process synchronization and 
communication. 

4. Inner Traffic Controller Eventcount Table (ITCSEVCSTBL) 

This is a global data base for the ITC level shown 
in Figure 43 and is used by the inter-virtual processor 
synchronization mechanism. 

This table is a parallel structure with the previously 

described EVCSTABLE. The differences are: the EVCSNAME 

in this table is not a character array but just a number (0 
to FFH). The reason is that this structure is invisible for 
the user and therefore it is not necessary to spend execution 
time to improve the "user interface" (viz., takes more time 
when we search the EVCSTABLE to find an eventcount name 


consisted of six characters). 
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TABLE 43. ITCSEVCSTBL (INNER TRAFFIC CONTROLLER EVENTCOUNT 
TABLE) 


This structure also uses the variable ITCSEVENTS 
(Inner Traffic Controller Events) to keep track of how many 
events are currently in use in the ITC level, for inter- 
virtual processor communication and synchronization. 

ey ocem Configuration Data Segment (SCDS) 

This is also a shared (global) segment containing 
the following information: 

NRSRPS (Number of Real Processors) provides the 
information how many phySical processors are currently used 
in the system. 

NRSVPS (Number of Virtual Processors) provides the 


number of virtual processors used in the system. It is 
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noted that NRSVPS = NRSRPS * VPSSPERSCPU, e.g., the number 
of virtual processors always equals to the number of real 
processors multiplied by the number of virtual processors 
per real processor, that is 4 in the current implementation. 

The array HDWSINTSFLAG(n) (Hardware Interrupt Flag), 
is used by the hardware interrupt mechanism for directing an 
interrupt to a specific physical processor. [Initially all 
the members of this array are set to zero. The number of 
these members is equal to NRSRPS (n = NRSRPS - 1). There is 
one-to-one mapping among HDWSINTSFLAG and CPUSNUMBER (or 
LOGSCPUSNUMBER), e.g., HDWSINTSFLAG(m) corresponds to 
CPUSNUMBER = m. The usefulness of these flags has already 
been discussed in paragraph G of this chapter. 

The array LOADSLIST(n) (Load List), is used in the 
implementation of the linked list of the processes loaded to 
each physical processor (The "Load List" discussed in the 
previous paragraph 2, above APT). Initially all the members 
of this array are set to zero. The number of these members 
is again equal to NRSRPS (n = NRSRPS -1l). There is also one- 
to-one mapping among LOADSLIST and CPUSNUMBER. LOADSLIST(m) 
points to the currently highest priority process (independent 
of whether this process is ready, running, or blocked) 
loaded on the physical processor with CPUSNUMBER (or 


LOGSCPUSNUMBER) = m. 


row 
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6. An Example for Loaced Lists and Blocked Lists 


It is now feasible to present an example to illustrate 
the interactions among LOADSTHREAD, THREAD, APTSPTR, and 
LOADSLIST. 

It is noted that it is important for the reader to 
understand the following example before proceeding into the 
details of the following paragraphs I (about the Inner 
Traffic Controller) and especially K (about the Traffic 
Selmerolier) . 

Figure 44 illustrates the interactions for this 
example. The APT, SCDS, and EVCSTABLE tables of Figure 44 
do not show all their members but only the ones needed to 
demonstrate the ideas. It is supposed that 11 processes 
corresponding to APT(0) through APT(10) entries of the APT 
have been loaded on three different physical processors with 
AFFINITY (CPUSNUMBER or LOGSCPUSNUMBER) 0, 1 and 2. 

Three linked "Loaded lists" are generated by the 
operating system, one "per physical processor". These three 
linked lists are sorted (ordered) by the priorities of the 
loaded processes. For example, the LOADSLIST(1) of the 
SCDS, corresponding to the physical processor with AFFINITY 
= 1 (LOGSCPUSNUMBER = 1) points to the highest priority 
process loaded on physical processor #1. It is shown in the 
Figure 44, that LOADSLIST(1) = 2. The meaning is that the 
LOADSLIST(1) (the header of this linked list) points to the 


entry 2 of the APT (APT(2)). In entry 2 of the APT, there 
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is loaded a process on physical processor #1 (AFFINITY = 1) 
and its priority is 30. On the same processor are loaded 
two more processes corresponding to the entries 5 and 9 of 
the APT but their priorities are lower (66 and 40 
respectively). 

The LOADSTHREAD corresponding to APT(2) is equal 
to 9. The meaning is that the next process loaded on this 
physical processor #l is in the entry 9 of the APT. Indeed 
the AFFINITY of APT(9) is also equal 1, and its LOADSTHREAD 
field is equal to 5. The meaning is that the next loaded 
process on this physical processor is in entry 5 of the APT. 
The LOADSTHREAD of APT(5) is equal to FF (the NIL pointer). 
This means this is the last process (the lowest priority 
process) loaded on physical processor #1. To summarize, we 
have LOADSLIST(1) = 2 pointing to APT(2) which is the highest 
priority process (with priority 30) loaded on this physical 
processor. This process points to the entry 9 (it has 
priority 40) and this second process in turn points to the 
entry 5 which contains the third process (with priority 66) 
and its LOADSTHREAD = FF meaning it is the last one in this 
linked list. 

Similarly, it is possible now to easily follow the 
path of the remaining two loaded lists (the linked lists of 
the processes loaded on physical processors #0 and #2). 

It is also supposed that several of these processes 


are in the blocked state waiting the occurrence of some 
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event. There exist three events in the EVCSTABLE with names 
WMEGA, GAMMA, and DELTA. The processes corresponding to the 
APT entries 5 and 10 are waiting for the occurrence of the 
event WMEGA, the processes corresponding to the APT entries 
2, 4, and 8 are waiting for the occurrence of the event 
GAMMA and finally the processes corresponding to the APT 
entries 1 and 7 are waiting for the occurrence of the event 
DELTA. 

Three linked "Blocked lists" are generated by the 
operating system one "per eventcount". For example, the 
APTSPTR corresponding to the EVCSNAME WMEGA is equal to 10. 
The meaning 1s that the EVCSTABLE(0).APTSPTR points to the 
entry 10 of the APT and indeed this process is waiting the 
occurrence of the event WMEGA. The THREAD field of the 
APT(10) is equal to 5. The meaning is that the process in 
APT(5) is also waiting the occurrence of the same event, and 
finally the THREAD field of APT(5) is equal FF meaning that 
there is no other process waiting the occurrence of the 
event WMEGA. It is noted that these linked lists are per 
eventcount and they link processes waiting the specific 
event independent of the processor on which they are loaded. 

Similarly it is possible now to follow easily the 
path of the remaining two blocked lists corresponding to the 


events GAMMA and DELTA. 
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7. Locks Table (LOCKS) 

This small global table consists only of the two 
following bytes: APTSLOCK and VPMSLOCK (Active Process 
Table Lock and Virtual Processor Map Lock). These two locks 
are used to prevent race conditions when accessing the 
shared data bases APT and VPM. The meaning and usefulness 
of these locks have already been discussed. 

8. Processor Data Segments (PRDS) 

This segment doesn't contain system-wide (global) 
data but "local" data, viz., data used for the specific 
microcomputer on which this segment is loaded. There exist 
a PRDS "per physical processor". This segment contains only 


the structure shown in Figure 45. 


DECLARE PRDS STRUCTURE 


(CPUSNUMBER Srln, 
VPSSTART BY EE 
VPSEND BYTE, 
VPSSPERSCPU BYTE, 
IDLESDBR WORD, 
COUNTER WORD, 
VIRTSINTSVECTOR POOTGER, 
HDWSINTSVECTOR PORMEER) 


FIGURE 45. PROCESSOR DATA SEGMENT STRUCTURE (PRDS STRUCTURE) 
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The CPUSNUMBER (A “unique" identification number for 
the specific physical processor) field, is assigned to each 
physical processor during system initialization and is equal 
to the LOGSCPUSNUMBER (Logical CPU number) passed as input 
argument to the module ITCSINIT (Inner Traffic Controller 
Initialization) which will be discussed in paragraph Ib of 
this chapter. Anderson [19] describes in his thesis the 
details about system initialization. 

The VPSSTART and VPSEND fields define the identifica- 
tion number of the first and last virtual processor assigned 
to the specific physical processor. For example, in this 
implementation, the physical processor with identification 
number CPUSNUMBER = 0 corresponds to VPSSTART = 0 and 
VPSEND = 3, the physical processor with CPUSNUMBER = 1 
corresponds to VPSSTART = 4 and VPSEND = 7, and so on. 

The VPSSPERSCPU (Virtual processors per CPU) field, 
determines the number of virtual processors assigned to each 
physical processor. In the current implementation this number 
is fixed and equal to 4. 

The IDLESDBR (Address space descriptor for the idle 
process) field determines the address of the base of the Idle 
Stack (IDLESSTACK) which is used by the Idle Process. Details 
about this stack will be discussed in the ITCSINIT module in 
paragraph Ib of this chapter. 

The COUNTER field is a software counter. By contain- 


| ing this member in the PRDS structure, which is local to each 
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microcomputer an array of software counters is automatically 
Bemerated with one-to-one correspondance to the physical 
processors. These counters are initialized to zero, and 


will be used to monitor the system's performance and the 


effectiveness of the partitioning of the application programs. 


Details will be discussed in paragraph Jb of this chapter. 
VIRTSINTSVECTOR and HDWSINTSVECTOR (Virtual interrupt vector 
and hardware interrupt vector) fields determine the address 
where the CPU of the specific microcomputer has to transfer 
the program control when it receives a virtual or a hardware 
interrupt. When a CPU receives a virtual interrupt, it 
transfers program control to the Traffic Controller Preemp- 
tion Handler (TCSPESHANDLER). This module will be described 
in the paragraph K, later on in this chapter. When a CPU 
receives a hardware interrupt, it transfers the program 
control to the hardware interrupt handler of the Inner 
Traffic Controller Scheduler (VPSCHEDULER). This module 
will be discussed in the paragraph Ia, later on, in this 
chapter. 
9. Sequencer Table (SEQSTABLE) 

This is a global data base for the TC level shown in 
Figure 46 and is used by the inter-process synchronization 
mechanism. 

The SEQSTABLE INDEX starts from zero and grows as 
new sequencers are added to the system by the application 


processes. For example, SEQSTABLE(0) represents the first 
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entry (horizontal line) in the SEQSTABLE, SEQSTABLE(1) the 


second and so on. 
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FIGURE 46. SEQSTABLE (SEQUENCER TABLE) 


The SEQSNAME (Sequencer name) field is a character 
array of six letters. The first five letters is the name 
given to the specific sequencer by the user and the last 
letter is a delimiter (% is used). This name is used as the 
eaput argument of the TCSTICKET (Traffic Controller TICKET) 
operation. 

The SEQSVALUE (Sequencer value) field holds the 
current value of the sequencer. Each time a TCSTICKET opera- 


tion is executed on the specific sequencer this value is incre- 


mented by one. 
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This structure also uses the variable SEQUENCERS with 
an initial value of zero. The value of SEQUENCERS is incre- 
mented by one each time the TCSCREATESSEQ (Traffic Controller 
Create Sequencer) is invoked by an application process. In 
this way the operating system keeps track of how many sequencers 
are currently in use for inter-process communication and 


synchronization. 


i fib INNER TRAFFIC CONTROLLER 

The Inner Traffic Controller comprises the lower level of 
processor multiplexing (Level 1 of this virtual machine). It 
multiplexes physical processors among a fixed set (four in the 
current implementation) of virtual processors. It provides 
inter-virtual processor communication and synchronization, 
Supports the management of physical resources and manages the 
system's interrupt structure. 

The Inner Traffic Controller creates a set of four virtual 
processors with the following extended instruction set: 
ITCSAWAIT, ITCSADVANCE, ITCSLOADSVP, IDLESVP, ITCSSENDSPREEMPT, 
and ITCSRETSVP. It also contains the internal routines 
HARDWARESINT, LOCKVPM, UNLOCKVPM, CHECKSPREEMPT, RDYTHISVP and 
SWAPDBR. 

ITCSAWAIT and ITCSADVANCE (Inner Traffic Controller AWAIT 
and ADVANCE) provide an inter-virtual processor synchronization 
mechanism used within the kernel to provide multiprogramming. 
This multiprogramming is realized by invoking the scheduling 


procedure GETWORK, of the ITC, which multiplexes these four 
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virtual processors on a physical processor. Which VP will 
finally run on the physical processor is decided by the 
VPSCHEDULER (Inner Traffic Controller Scheduler). 

ITCSLOADSVP (Inner Traffic Controller Load Virtual Pro- 
cessor) performs the "binding" of a new process to a virtual 
processor. It is called by the TCSSCHEDULER (Traffic Control- 
ler Scheduler) when a process has been selected for the VP. 

IDLESVP (Idle this VP) is the ITCSLOADSVP's counterpart. 
It is called by the TCSSCHEDULER in case that there exist no 
runnable process for the VP. The virtual processor will be 
idled (enter the "idle state"). 

CHECKSPREEMPT and ITCSSENDSPREEMPT (Check for Pending 
Beeemot interrupt and ITC Send Preempt Interrupt) create a 
Virtual processor interrupt mechanism. CHECKSPREEMPT, when 
it is invoked within the ITC, checks the PESPEND (Preemption 
Pending Flag) field of the VPM to determine if it is set or 
reset for the specific VP. ITCSSENDSPREEMPT is invoked from 
level 2 (TCSADVANCE) when the Traffic Controller desires to 
load a new process on a virtual processor that is not 
scheduled. 

ITCSRETSVP (Inner Traffic Controller Return Virtual Pro- 
cessor's identification number), when it is invoked, provides 
the information which VP is currently scheduled (running) on 
the physical processor. This identity is only valid so long 
as the APT is locked. The identity of a particular VP must 


be known in the virtual environment, just as the identity of 
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a physical processor is required to be known in the multi- 
processor system. 

HARDWARESINT (hardware interrupt) is used within the ITC 
to send a hardware interrupt from one physical processor 
to another. The purpose is to support preemptive scheduling 
needed in the real-time processing. 

LOCKVPM and UNLOCKVPM (Lock and Unlock the Virtual pro- 
cessor map) are used to set or reset a software lock on the 
Shared (global) VPM data base to assure there are no race 
Eeenmditions. 

RDYTHISVP (Ready this VP) is used to change the state of 
the currently “running" VP to "ready". 

SWAPDBR (Swap DBR) is a function within the Inner 
Traffic Controller Scheduler and is used to change the 
address space when a new process is scheduled to run when 
the previous process has been completed or blocked. 

The details of the Inner Traffic Controller modules will 
be discussed below: 

1. Virtual Processor Scheduler (VPSCHEDULER) 

This module is responsible for making the scheduling 
decisions for virtual processors. It selects the highest 
priority virtual processor from the set of four virtual 
processors assigned to the physical processor and schedules 
it. There are two distinct entry points to the VPSCHEDULER, 


the normal entry and the interrupt entry. 
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The normal entry point is used by other Inner 
Traffic Controller modules to activate VPSCHEDULER when a 
virtual processor gives up the physical processor on its 
own. The preempt interrupt entry point is used in response 
to a hardware preempt interrupt from another physical 
processor. 

VPSCHEDULER next searches through the fixed set of 
virtual processors for the highest priority "eligible" 
Virtual processor. In this implementation the definition of 
eligible includes not only a ready VP but also the combina- 
tion of an idle state and a pending virtual preempt interrupt. 
This allows an idle virtual processor to run so that it may 
field the interrupt and bind itself to a new process. The 
idle process that was bound to the virtual processor was 
essentially useless up to this point. It now provides an 
address space in which the virtual processor can execute 
when binding to a new process. 

Having selected some eligible virtual processor, the 
VPSCHEDULER proceeds to bind the selected virtual processor 
to the physical processor. It begins by unbinding the 
currently running virtual processor. In doing so, the Stack 
Pointer Register (SP) value, and the Base Pointer Register 
(BP) value are saved in known locations on the process' 
stack. The process' execution state (point) had already 


been saved. 
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Binding the selected virtual processor is begun by 
changing the Stack Segment (SS) Register value to that of 
the selected virtual processor. Once this change has been 
made, execution has actually swapped to the new process 
address space. Binding is completed by retrieving the 
previously saved stack Pointer Register value and the Base 
Pointer Register value from the newly acquired stack. 

The last step is to actually return to the proper 
place in the VPSCHEDULER. If a preempt interrupt invoked 
VPSCHEDULER, an interrupt return will be executed and 
CHECKPREEMPT will see if a virtual preempt interrupt is 
pending. If a preempt interrupt is found to be pending, the 
program control will be transferred to the location specified 
Pye Res .VIRTSINTSVECTOR (viz., to the Traffic’ Controller's 
preempt handler). 

There is one other internal module for the Virtual 
Processor Scheduler, the hardware interrupt handler. It is 
used to handle hardware preempt interrupts. The program 
control is transferred in this module each time the HARD- 
WARESINT module of the ITC is invoked. Details about the 
hardware preempt interrupt mechanism have already been 
discussed in the paragraph G of this Chapter. (For the 
algorithm see Figure 38). 

2. BP@SiInet Cinner Traffic Controller Initialization) 

This module together with the following KERNELSINIT 


perform part of the system initialization by initializing the 
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stack of the Idle Process and also the stack of the Memory 
Management Process. These two system processes run concept- 
ually between the TC and ITC levels as shown in Figures 5 and 
9. These two processes are scheduled by the VPSCHEDULER 
(the ITC scheduler), and are "invisible" to the TCSSCHEDULER 
(generally to the TC level). That means there is no entry 
into the APT (Active Process Table) for these two processes. 
Also the stack initialization for these processes is differ- 
ent from the corresponding initialization of an application 
process stack. Details about these two system processes 
will be discussed after the completion of the ITC level. 

This module just calls the KERNELSINIT module and 
then calls the VPSCHEDULER that schedules the highest priority 
virtual processor (VP #0) to run. VP #0 is permanently bound 
to the Memory Management Process. 

ITCSINIT accepts two input arguments, CPUSNUMBER (that 
is equal to the LOGSCPUSNUMBER, logical CPU number) and 
PHYSSCPUSNUMBER (physical CPU number). These two arguments 
LOGSCPUSNUMBER and PHYSSCPUSNUMBER are given values during 
the system initialization [19]. 

ITCSINIT is the entry point for the distributed oper- 
ating system. 

Pe RERNERS INIT «(Kernel Initialization) 

This module is called only by the ITCSINIT and is 

executed by each processor once during the system 


initialization. It declares the IDLESSTACK and MGMTSSTACK 
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(Idle Process Stack and Memory Management Stack respectively) 


as based structures. It then initializes these two stacks by 
initializing the header of the stack and the register's 
array and then initializing the maximum stack length, and 
the process' initial code segment (CS) register, instruction 
pointer (IP) register and the flags. (See Figure 22). 

Then the program control returns into ITCSINIT 
module. 

4. GETSCOUNTER (Get Current Value of COUNTER) 

This is just a "utility function" called only by the 
Idle Process. It gets the current value of the counter 
(which is a member of the PRDS, (see Figure 45)) and returns 
that value to the Idle Process. 

Dee UPDATE SCOUNTER (Update the Value of COUNTER) 

This is also a "utility function" called only by the 
Idle Process and has the purpose to update (increment by 
one) the current value of the COUNTER. The usefulness of 
these two utility functions will be discussed when describ- 
ing the Idle Process. 

6. GETSCURRENTSDBR (Get Current DBR) 

This is also a "utility function" and is called only 
by the VPSCHEDULER. When making an implicit call to the 
ITCSRETSVP (discussed below), it finds the identity (VP 
number) of the currently running virtual processor and then 
finds and returns the content of the Stack Segment (SS) 


register, corresponding to the specific running VP. Recall 
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that the SS register is used in this design in a manner 
analogous to the DBR in the MULTICS system. This DBR 
value is used by the VPSCHEDULER to identify the right 
address space and continue execution after receiving a 
hardware interrupt. 

We note here that each time a module returns a func- 
tion value, this value in PLAt86 always goes into the 
accumulator (AX) register. 

7. ITCSRETSVP (Inner Traffic Controller Return VP Number) 

This is also a “utility function" used by the Inner 
Traffic Controller and Traffic Controller modules. ITCSRETSVP 
searches the Virtual Processor Map and determines the identity 
of the virtual processor that is currently running on the 
physical processor. It simply checks for the virtual 
processor among the virtual processors assigned to the 
physical processor which is in the running state. ITCSRETSVP 
then returns its result as a function value into the AX 
(accumulator) register. It will return either the identity 
of the virtual processor (the virtual processor's index in 
the Virtual Processor Map) or a “not found" error code. 

8. ITCSRETSVPTC (ITC Return VP number for TC) 

It is a "utility function" which is used to perform 
the VP mapping between the TC and ITC levels as already 
Mentioned in paragraphs Hl and H2 (about VPSID Field) of 


this Chapter. 
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Ali the four VP's in the Figure 39 are visible to 
the ITC. The two central VP's are visible to the TC while 
VPSSTART and VPSEND are invisible. The user processes are 
multiplexed among these two central VP's of each physical 
processor. 

The ITCSRETSVPTC when called by the TC, it calls in 
Buen the ITCSRETSVP to obtain the currently running VP (its 
index in VPM). It then performs the mapping shown in Figure 
47, and finally returns the corresponding VP identification 
number for the TC (VPSID in Figure 47). 


Petco obLOADSVP (Inner Traffic Controller Load Virtual 
Processor) 


This module performs the "binding" of a new process 
to a virtual processor. It is called by the Traffic Controller 
Scheduler (TCSSCHEDULER) when a process has been selected for 
the virtual processor. LOADSVP requires two input parameters, 
the priority of the new process and the address space descriptor 
(the Stack Segment Register value). It then swaps in the new 
process onto the virtual processor which is currently running. 
ITCSLOADSVP only operates on the virtual processor which is 
running on the physical processor. 

Binding is accomplished by updating the Virtual Pro- 
GCessor Map. The Inner Traffic Controller utility function 
ITCSRETSVP is used to obtain the identity of the running 
Virtual processor. When complete, the virtual processor will 


have a new priority and process address space descriptor 
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(corresponding to the priority and address space of the pro- 
cess just bound to it). ITCSLOADSVP completes by calling 
VPSCHEDULER to reschedule the virtual processor. 

10. IDLESVP (Idle this Virtual Processor) 

Gas function is ITCSLOADSVP's counterpart. It is 
Called by the TCSSCHEDULER (Traffic Controller Scheduler) in 
the event that a runnable process is not found for the virtual 
processor. In this case the virtual processor will be idled 
(enter the idle state) and the Idle Process will be bound to 
it. In the Virtual Processor Map, the virtual processor's 
state will be marked as idle, the address space descriptor 
for the Idle Process will be entered in the Address Space of 
Bound Process field. The idle state ensures that the idle 
process is not actually run by taking the virtual processor 
entirely out of contention for the physical processor, with 
which this virtual processor is associated. 

At some later point, the virtual processor may be 
placed back in “contention" for resources. This will occur 
when the virtual processor is "preempted". With the combina- 
tion of an "idle state" and a "pending preempt", the virtual 
processor is treated the same way as a "ready" virtual proces- 
sor (We shall clarify that statement when describing the 
GETWORK module). This allows the virtual processor to keep 
busy by expediting its binding to a process. 

Lastly IDLESVP calls VPSSCHEDULER in order to "give 


up" the physical processor. 
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ie CHECKSPREEMPT (Check for Pending Preempt Interrupt) 
This module is called by the VPSCHEDULER during the 


execution of a "virtual interrupt return". It checks for a 
pending preempt interrupt meant for the virtual processor, 
which has been selected to run (the running VP) by the 
VPSCHEDULER. To accomplish this it checks the virtual 
processor's "preempt pending flag" (PESPEND) in the VPM 
(Virtual Processor Map). If the preempt pending flag is set, 
the CHECKSPREEMPT will reset it and return the found value 
(flag "on" or "down") to the VPSCHEDULER. In this way the 
VPSCHEDULER is informed about the state of PESPEND flag and 
it will use this information to decide which VP will run 
(see GETWORK module below). 
12. GETWORK 

It is a function call. Initially it sets its local 
variable PRI (Priority) equal to the lowest possible priority. 
(In this implementation, the lowest priority is 255 and the 
highest is 0) and SELECTEDSDBR (selected address space) 
equal to IDLESDBR (the address space for the idle process). 

It then searches the VPM (Virtual Processor Map) to 
Find the highest priority, "eligible" to run, virtual processor. 
In this implementation eligible to run for a virtual processor 
means it is either in the "ready" state, or the "idle" state 
with a "virtual preempt pending" (PESPEND is set). 

Using the above criterion, GETWORK selects an eligible 


processor, sets the SELECTEDSDBR and PRI equal to the 
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corresponding VPM values SSSREG and VPSPRIORITY respectively 
for the selected VP, and then sets its state to "running" 
and finally returns the SELECTEDSDBR into the Accumulator. 

If after the above search no eligible VP is found, 
it defaults SELECTEDSDBR = IDLESDBR and the idle process 
Wall run. 


13. ITCSSENDSPREEMPT (Inner Traffic Controller Send 
Preempt Interrupt) 


This module is responsible for actually sending pre- 
empt interrupts. It is called by the Traffic Controller 
Advance module. ITCSSENDSPREEMPT requires two arguments, the 
identity of the virtual processor which is to be preempted 
and the identity of the physical processor to which that 
Virtual processor is associated. 

It first locks the VPM (Virtual Processor Map) and 
then sets the virtual processor's PESPEND (Preempt Pending 
Flag). This is all that is done when the virtual processor 
to be preempted is associated to the physical processor, which 
is the transmitter (executing the ITCSSENDSPREEMPT module). 
In other words, when the TGTSCPU (the input argument showing 
the identity of the physical processor possessing the 
Virtual processor for which the virtual preempt interrupt is 
destined) is equal to the CPUSNUMBER (the identity of the 
physical processor executing ITCSSENDSPREEMPT) . 

Otherwise, after setting the PESPEND the ITCSSENDS- 


PREEMPT calls the HARDWARESINT procedure (see next paragraph) 
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to generate a hardware interrupt for the physical processor 
possessing the virtual processor to be preempted. 

Finally the ITCSSENDSPREEMPT unlocks the VPM and 
returns to the TCSADVANCE (the module responsible for pre- 


emptive scheduling). 


14. HARDWARESINT (Hardware Je geteese(b Sey) 


This procedure requires as its input argument the CPUS- 
NUMBER, viz., the identity of the physical processor for which 
the hardware interrupt is destined. HARDWARESINT procedure 
first sets the "global" hardware interrupt flag corresponding 
to this physical processor (HDWSINTSFLAG(CPU)). It then 
sends a hardware interrupt by outputting in the parallel 
PORT "C", first a "0" then an "80H" and again a "0". 
Finally the program control returns to the calling procedure. 
The details about this hardware preempt interrupt already 
have been discussed in paragraph G of this chapter. HARD- 
WARESINT is called only by the ITCSSENDSPREEMPT and 
ITCSADVANCE modules. 

ae LOCKVEM (Lock Virtual Processor Map) 

This small module uses a built-in PL/M-86 procedure 
Called LOCKSET which is an “indivisible test-and-set semap- 
hore" to implement a software lock called LOCKSVPM in the 
VPM which is the central shared data base in the Inner 
Traffic Controller Level (see Figure 9). Because this 


global data base can be accessed (read and write capability) 
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by all the virtual processors, this lock is used to prevent 
"race conditions”. 
16. UNLOCKVPM (Unlock Virtual Processor Map) 
This module is the counterpart of the above LOCKVPM. 
Each time we have to access the VPM, we first lock the 
VPMSLOCK. When the access task is finished, we have to 
unlock this VPMSLOCK, so that another virtual processor can 
access it. 
17. RDYTHISVP (Ready this Virtual Processor) 
This module first finds which Virtual Processor is 
currently running by calling implicitly ITCSRETSVP and then 
changes the state of this VP from "running" to "ready". 


me  L@©TCSLOGATESEVC (Inner Traffic Controller Locate 
Eventcount) 


This is a utility function. It returns the index of an 
mpc Evyentcount in the ITC Eventcount Table (ITCSEVCSTBL). It 
is called only by ITCSAWAIT and ITCSADVANCE described below. 
The input argument is the name of this ITC Eventcount. ITCS- 
LOCATESEVC attempts to match the name given to it with one in 
the ITCSEVCSTBL. If a match is found, it returns the index 
to the calling procedure in the AX (Accumulator) Register as 
a function value. Otherwise, it returns an error code. 

19. ITCSAWAIT (Inner Traffic Controller AWAIT) 

ITCSAWAIT is an inter-virtual processor synchroniza- 

tion primitive. It is "invisible" (not accessible) to the 


user processes and is used only by the operating system in 
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the management of physical resources. It allows a virtual 
processor to wait for the occurrence of an ITC Eventcount. 

ITCSAWAIT expects two input arguments, the name of 
the Eventcount and the value of the event to be awaited. 

Upon invokation ITCSAWAIT locks the VPM. It then 
finds first which Virtual Processor is running by making an 
implicit call to the ITCSRETSVP and then finds the index of 
the Eventcount in the ITCSEVCSTBL by making an implicit call 
to the ITCSLOCATESEVC. It then compares the current value 
of the Eventcount, obtained from the ITCSEVCSTBL with the 
value passed in the call. If the current value of the 
Eventcount is found to be less than the value of the input 
argument, then the virtual processor will enter the "waiting" 
state and "gives up" the physical processor. 

This change of the virtual processor's state from 
"running" to "waiting" will be reflected in the VPM. The 
input arguments will also be entered in the VPM in the 
EVCSAWSID (Identity of the Awaited Eventcount) and the 
EVCSAWSVALUE (Eventcount Awaited Value) fields. 

Otherwise, if the current value of the Eventcount is 
found to be equal or greater than the value of the input 
argument, then the state of this virtual processor will be 
changed from "running" to "ready". 

Finally, in both cases the virtual processor will 


give up the physical processor by calling the VPSCHEDULER, 
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which will bind another (or possibly the saitie” ) virtual 
processor to this physical processor. Upon the return from 


the VPSCHEDULER, the VPM will be unlocked. 


20. ITCSADVANCE (Inner Traffic Controller ADVANCE) 

ITCSADVANCE is an inter-virtual processor synchroniza-~ 
tion primitive. It also is "invisible" to the user processes 
and is used only by the operating system in the management of 
the physical resources. It expects one input argument, the 
name of the ITC Eventcount to be advanced. 

Upon invocation, the VPM is locked. ITCSADVANCE then 
finds which VP is running by making an implicit call to the 
ITCSRETSVP to change the state of this VP from "running" to 
"ready". It then finds the index of the Eventcount in the 
SiGomvCoTBL by making an implicit call to the ITCSLOCATESEVC, 

and the eventcount's value in this table is incremented by 
one. 

ITCSADVANCE then compares this incremented value with 
the events waited for by the other virtual processors which 
are synchronizing on the same eventcount. All those virtual 
processors whose Eventcount Awaited Value field (EVCSAWSVALUE) 
in the VPM is less than or equal to the current value of the 
eventcount are set to the "ready" state. This is the "broad- 
cast effect" discussed in paragraph F5e3 of this chapter. 


twill be the same only in case the state of the 


VP changed from "running" to "ready" and if this is 
1 the highest priority ready VP. 
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Finally, the ITCSADVANCE calls VPSCHEDULER to schedule 
the next VP. Upon return from VPSCHEDULER, it will unlock 


the VPM. 


m=. KERNEL PROCESSES 

The kernel processes make up the non-distributed kernel. 
Non-distributed here has the meaning that these processes are 
not distributed as part of each process's address space. 
Instead they represent system services and are used in the 
management of physical resources and execute asychronously 
with respect to user processes. 

In this implementation all system processes are permanent- 
ly bound to dedicated virtual processors, because it is very 
expensive to use a dedicated real processor. 

Currently, two kernel processes are used, the Memory 
Management Process and the Idle Process (MMGT and IDLE Process 
respectively). The MMGT process controls both primary and 
secondary memory and the IDLE process defines the "no work" 
State of the system. 

The currently implemented MMGT and IDLE processes do not 
have their final form. Instead they are "stubs" for these 


processes. The current implementation does provide the 


interface of these processes with the operating system and the 


inter-virtual processor synchronization mechanism, which is 
the most difficult task when implementing such processes. 


(This inter-virtual processor synchronization mechnism will 
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also be used in the future when Input/Output management will 
be added to the system.) 
= tne Memory Management Process (MMGT Process) 

The currently implemented MMGT process is permanently 
bound to the VPSSTART (see Figure 39) and the IDLE process 
is permanently bound to the VPSEND. In this way these two 
virtual processors are in contention for physical processors 
but not for application (user) process scheduling. 

Anderson [19] in his thesis describes the system- 
wide initialization. Below is described what is going on 
in each physical processor. 

Each physical processor starts executing in the code 
of the ITCSINIT module (see paragraph I2 of this chapter). 
This module ends with a call to VPSCHEDULER. The VPSCHEDULER 
schedules the highest priority (i.e., VPSSTART) virtual 
processor to run on each physical processor. In this way 
each physical processor executes the MMGT process as its 
first process. 

The MMGT process calls the loader module which 
repeatedly calls the CREATESPROCESS module. When the loader 
is finished, the number of APT entries (processes) is equal 
to the number of application processes to be loaded. The 
module CREATESPROCESS (See paragraph K10 in this chapter) 
initializes the address space (stacks) for each process and 
Finally calls the module AWAITSFORSSTART (see paragraph K8). 


The result is that each newly created process becomes blocked 
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meeting for the special eventcount "START", with initial 
value zero, to reach the value l. 

When no other process remains to be loaded the MMGT 
process invokes ADVANCESFORSSTART. The result is that the 
value of this special eventcount START reaches the value 1 and 
all the created processes on its blocked list (see Figure 44) 
are now awakened. 

Then the MMGT process calls the module ITCSAWAIT 
(see paragraph I19 of this chapter). The result is that the 
VPSSTART enters the waiting state and finally the VPSCHEDULER 
1s invoked. The VPSCHEDULER will schedule the VP which is 
loaded with the highest priority application process (one of 
the two central VP of Figure 39) since the VPSEND is bound 
to the IDLE process. If no application processes are loaded 
on the specific physical processor, the VPSCHEDULER will 
schedule the lowest priority VPSEND to run the IDLE process, 
Since the highest priority MMGT process 1s currently blocked. 

2. The Idle Process (IDLE Process) 

The IDLE process defines the "no work" state of the 
system. The operating system attempts to schedule useful 
work on system processors whenever feasible. If there is no 
work then the IDLE process assures that the physical processor 
always has some valid process address space to execute in. 
The idle virtual processors act as "default" processors that 


will only be run when no other eligible VP is found. 
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Currently the IDLE process constitutes just an "idle 
loop". When the IDLE process is running, the this loop is 
first entered the current value of the PRDS software COUNTER 
(see paragraph H8 of this chapter) is obtained. Afterwards 
each time this idle loop is executed this COUNTER is updated 
(see also paragraphs I4 and I5). 

By being able to read the value of these COUNTERS 
(one per physical processor) the performance of the operating 
system, the hardware communication links between different 
"clusters" and finally the effectiveness of the 
application processes "partitioning" can be actually tested. 

The reason is, this COUNTER value records how much 
time each real processor executed in the IDLE process. These 
values can be interpreted and used as relative time or as 
actual time by multiplying the COUNTER's value by the time 
needed this idle loop to be executed once. 

When in the future the preventive fault diagnosis 
and recovery routines are developed, part of these routines 
will be incorporated into the IDLE process, so that when a 
physical processor has no work it will execute this preventive 


fault diagnosis routine instead of idling. 


K. THE TRAFFIC CONTROLLER 
The Traffic Controller resides at level 2, multiplexes 
the user processes among virtual processor and manages the 


execution of these processes (process management) by invoking 
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the extended instructions of the virtual processors in level 
1 (ITC-level). In addition to implementing the level 2 
scheduling algorithm, the Traffic Controller creates the ex- 
tended instruction set: TCSAWAIT and TCSADVANCE. 

TCSAWAIT and TCSADVANCE (Traffic Controller AWAIT and 
ADVANCE) are used to implement an inter-process communica- 
tion and synchronization mechanism invoked by the Supervisor, 
by uSing the eventcounts and sequencers. 

The Traffic Controller's principal global data base (APT) 
has already been discussed in paragraph H2 of this chapter. 
Each entry of the APT corresponds to an application process 
and contains sufficient information to enable a virtual pro- 
cessor to be bound to and execute it. 

1. Process Scheduler (TCSSCHEDULER) 

The TCSSCHEDULER works in essentially the same way 
that the Inner Traffic Controller's Scheduler (VPSCHEDULER) 
does. However, the TCSSCHEDULER schedules processes, while 
the VPSCHEDULER schedules virtual processors. The 
TCSSCHEDULER can be called by the TCSAWAIT, TCSADVANCE, and 
TCSPESHANDLER (Traffic Controller Preemption Handler). 

It selects the highest priority ready process from 
the specific microcomputer's Loaded List (see Figure 44) to 
be bound to an available virtual processor. The TCSSCHEDULER 
works only with the processes which are runnable on its own 
physical processor using the fixed set of the four virtual 


processors assigned to this physical processor. 
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When the TCSSCHEDULER finds a runnable process, the 
Inner Traffic Controller module ITCSLOADSVP is called to bind 
the selected process to the running virtual processor. Alter- 
natively, if there is no runnable process, the virtual pro- 
cessor will be idled (bound to the Idle Process and placed 
in the idle state) by a call to the Inner Traffic Controller 
module IDLESVP. 

2. Traffic Controller Locate Eventcount (TCSLOCATESEVC) 

This is a “utility" function called only by the 
Traffic Controller modules TCSAWAIT and TCSADVANCE. Together 
with the following module TCSLOCATESSEQ it is used to simplify 
the handling of eventcounts and sequencers respectively. 

Its input argument iS a pointer to the name of the 
eventcount. When invoked, TCSLOCATESEVC makes a linear 
Search in the Eventcount table (EVCSTABLE) to locate the 
desired eventcount by matching the names. If a match is 
found it returns the index of the specific eventcount in the 
EVCSTABLE in the Accumulator (AX) register, otherwise (if 
not found), it returns an error code. 

3. Traffic Controller Locate Sequencer (TCSLOCATESSEQ) 

This is the second "utility" function used in the 
handling of sequencers and is called only by the TCSTICKET 
traffic Controller TICKET) module. 

TCSLOCATESSEQ works in exactly the same way as the 
LOCATESEVC does except that it searches for sequencers in 
the Sequencer Table (SEQSTABLE) instead of eventcounts in 
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fw Geaeric Controller AWAIT (TCSAWAIT) 

The TCSAWAIT is an inter-process synchronization 
primitive visible to the user, via the "GATE. It allows a 
process to suspend its own execution pending the occurrence 
of a specified event. TCSAWAIT is called with two input 
arguments, (a pointer to) the name of the eventcount and the 
value (of the event) to be awaited. 

Upon invokation, Await locks the Active Process Table 
mma then calls the Inner Traffic Controller utility function 
ITCSRETSVPTC to obtain the identity of the running virtual 

processor. This is used in a search of the Active Process 
Table to identify the process which invoked the TCSAWAIT. 
Once the calling process has been identified, an 
implicit call is made to the TCSLOCATESEVC to locate the 
index in the EVCSTABLE of the input argument (eventcount 
name). Then the current value of the eventcount kept in the 
EVCSTABLE is compared to the awaited value specified in the 
call. If the event has not yet occurred (viz., the current 
value in the EVCSTABLE is less than the awaited input 
argument value), then the process will enter the blocked 
State. The Value of Eventcount Awaited field in the Active 
Process Table is updated with the awaited argument value and 
| the process is placed on the eventcount's Blocked List (see 
Figure 44). Otherwise, if the event has already occurred 
(viz., the current value is greater than or equal to the 
awaited input argument value), then the process is not 


blocked but is made ready. 
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Finally, in both cases, TCSAWAIT calls the TCSSCHEDULER 
to schedule the highest priority ready process. Upon the 
return from TCSSCHEDULER it unlocks the Active Process 
wable. 

Se ltattic Controller ADVANCE (TCSADVANCE) 

The TCSADVANCE is an inter-process synchronization 
primitive visible to the user, via the "GATE". It allows a 
process to signal the occurrence of an event. It updates 
the eventcount and signals those processes which had blocked 
themselves for this event. Thus TCSADVANCE is also responsi- 
ble for invoking the preemption mechanism. 

TCSADVANCE is called with one input argument, (a 
pointer to) the name of the eventcount being advanced. 

It first locks the Active Process Table, then makes 
an implicit call to the TCSLOCATESEVC to locate the index in 
the EVCSTABLE of the input argument (eventcount name). Then 
the current value of the eventcount in the EVCSTABLE is 
incremented by one. The eventcount's Blocked List (see 
Figure 44) is searched for processes which had previously 
blocked themselves waiting for the same eventcount to reach 
this value. As processes are found that should be awakened, 
viz., 1f the current value of the eventcount in the EVCSTABLE 
1s greater or equal to the EVCSVALUESAW (awaited eventcount 
value) field of the APT corresponding to the specific process, 

: then these processes are made ready. 
| 
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An entry in a temporary array of physical processors 
is now made to record the physical processor in whose local 
memory the newly awakened process is loaded for preemption. 
The awakened process is then removed from the eventcount's 
Blocked List. 

Once all of the processes to be awakened have been 
found, TCSADVANCE determines which virtual processors must 
be preempted. This is done for each of the previously 
flagged physical processors by first assuming that all of 
the physical processor's TC-visible virtual processors (two 
in this implementation) should be preempted. Then the 
decision is made as to which ones will not be preempted. 
This method greatly simplifies the algorithm. First a 
temporary list (array) of virtual processors is initialized 
to indicate a virtual preempt for each of the virtual 
processors. The Loaded List is then searched to find those 
processes which should be running. The processes which 
should be running are those with the highest priorities that 
are either in the "ready" or the "running" states. Assuming 
that there are 2 virtual processors per physical processor 
used for multiplexing, then the 2 highest priority "ready" 
or "running" processes in the Loaded List should be running. 
Any lower priority processes that actually are running 
should be preempted. TCSADVANCE determines which or the 
processes that should be running already are running and 


deletes their virtual processors from the preemption list 
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(resets the preempt flag in this array). What will remain 
at the end are those virtual processors that are to be 
preempted. 

The next step is to actually issue the preempt 
interrupts. The temporary preempt list is checked and if a 
preempt is indicated for a virtual processor, the Inner 
Traffic Controller module ITCSSENDSPREEMPT is called to 
actually issue the preempt. 

TCSADVANCE next readies the process which invoked it 
and calls the TCSSCHEDULER. Upon the return from the TCS- 
SCHEDULER the Active Process Table is unlocked. 

meee eattic Controller Ticket (TCSTICKET) 

The routine TCSTICKET is also used in the inter- 
process synchronization and communication mechanism. It is 
the only operation performed on sequencers. It expects one 
input argument, (a pointer to) the sequencer name and it is 
Visible to the user via the "GATE". 

When invoked, TCSTICKET locks the Active Process 
Mable, and calls implicitly the TCSLOCATESSEQ to find the 
index in the global sequencer table (SEQSTABLE) of the 
sequencer name given to it as the input argument. It then 
obtains from the SEQSTABLE the current sequencer value 
(SEQSVALUE) corresponding to the specific index and returns 
this sequencer's value to the process which called the 
TCSTICKER. The value according to the PL/M 86 language 


conventions is returned to the accumulator (AX) register. 
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Before returning, TCSTICKET increments by one the 
value of the sequencer and finally unlocks the Active Process 
Table. 

In this way, TCSTICKET returns an unique sequencer 
value with every invokation, which will always be one more 
than the last value returned in the same way that TCSADVANCE 
increments the eventcount value (EVCSVALUE). This is the 
reason why eventcounts and sequencers were defined as "positive 
non-decreasing integers". 

feeetaaetic Controller Preemption Handler (TCSPESHANDLER) 

The TCSPESHANDLER is not a separate procedure but is 
just a label in the main program of the TC. 

It serves as the virtual preempt interrupt entry 
point into TCSSCHEDULER and is invoked only by the Inner 
Traffic Controller Scheduler (VPSCHEDULER) in the course of 
virtualizing preempt interrupts. Actually the VPSCHEDULER 
transfers the program control, via the virtual interrupt 
feeeer, tO the global label TCSPESHANDLER. Recall that the 
wietual interrupt vector residing in the PRDS (VIRTSINTS- 
VECTOR) 1S initialized to point to the TCSPESHANDLER label. 

The TCSPESHANDLER first locks the Active Process 
Table, then calls the TCSSCHEDULER which will find the highest 
priority ready process and bind it to the preempted virtual 
processor. Upon return from the TCSSCHEDULER the program 
control is transferred back to the VRSCHEDULER, effecting a 


eylrtual interrupt return". 


se | 





8. Await For Start (AWAITSFORSSTART) 

This module is a part of TCSAWAIT and is called only 
Once, during system initialization, by the MMGT process. It 
is invisible to the user. 

It accepts three input arguments, the index of the 
process in the Active Process Table assigned by the CREATES- 
PROCESS (Create Process) module discussed in paragraph 9 
below, the eventcount name and the eventcount value to be 
awaited. There is in the system a special eventcount named 
"START" with initial value zero. The second input argument 
is the name of this special eventcount and the third, the 
awaited value, which is always one. 

Each time the CREATESPROCESS is called to create a 
process, the last statement is a call to AWAITSFORSSTART 
(Process, Start, 1). In this way each newly created process 
after creation is set to the blocked state awaiting for the 
special event START to reach the value 1. Each new process 
is added to the blocked list (see Figure 44) for the event- 
eount START. 

9. Advance For Start (ADVANCESFORSSTARS ) 

This module is a part of TCSADVANCE and is also 
called only once during the system initialization by the MMGT 
process. It is invisible to the user. 

It accepts one input argument (a pointer to) the name 
of the eventcount START. Where invoked it advances (incre- 


ments by one) the value of the special event START. The 
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result is that the value of START, initially zero, reaches 
for every new process the awaited value of 1. Then using 
the existing signalling mechanism, (the same as in the 
TCSADVANCE module), ADVANCESFORSSTART awakes each process on 
the START eventcount's blocked list and sets its state to 
ready. 

The created processes are now in contention for 
processor resources. The same sequence of actions will be 
followed as in the case of TCSADVANCE except that ADVANCES- 
FORSSTART doesn't ready the calling process (which is the 
MMGT process) and also doesn't call the TCSSCHEDULER but 
merely returns program control to the caller, the MMGT 
process. 

Qe Create Process (CREATESPROCESS) 

The CREATESPROCESS module provides the capability 
to dynamically create processes. It is called with one input 
argument, a pointer to a process parameter block (PPB) struc- 
ture containing all the information necessary to initilize 
the process's stacks and enter the newly created process into 
the Active Process Table. All of the process’ segments had 
previously been loaded into memory by the system loader, as 
described by Anderson [19]. 

CREATESPROCESS first locks the Active Process Table. 
The next step is to enter the process in the Active Process 
Table. To create this entry the traffic controller uses the 


parameters passed by the PPB structure (see MMGT Process in 
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Previous paragraph Jl of this chapter). The process is also 
anserted into the Load list based on its priority, viz., 
CREATESPROCESS searches down the LOADSLIST corresponding to 
the physical processor on which this process is loaded and 
sets the LOADSTHREAD field (see Figure 44) in such a way 
that the currently created process is entered immediately 
ahead of the first process found to have lower or equal 
@coiority. 

Then CREATESPROCESS initializes two stack frames for 
this process: the KERNELSSTACK and USERSSTACK corresponding 
to the kernel and user domain respectively. In this way the 
process' address space is divided into these two separate 
domains of execution. The kernel stack has already been 
discussed in Paragraph E of this chapter (see also Figure 26). 
The user stack is shown in Figure 48 and the relation between 
these two stacks in Figure 49. Since in the PL/M-86 language 
the stack grows downwards (see Figure 22) by keeping the 
kernel stack above the user stack the KERNELSSTACK is protect- 
ed from accidental user tampering (viz., overwriting KERNELS- 
STACK is avoided). 

The location of these stacks and the initial register 
values (viz., initial values for all of the 8086's registers) 
for the specific process are passed by the PPB structure and 
used in the initialization of the stack frames. 

Finally, CREATESPROCESS unlocks the Active Process 


Table and calls AWAITSFORSSTART (Await for Start) to block 
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HIGH 
MEMORY 
CPU FLAG REGISTER CONTENTS INTERRUPT FRAME 
(STORED BY HARD- 
RETURN SEGMENT ADDRESS WARE IN RESPONSE 
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(IP REGISTER CONTENT) 
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FIGURE 48. USER STACK AFTER RESPONDING TO AN INTERRUPT 
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HIGH KERNEL STACK 


USER S$ SP SWITCH SEE FIGURE 26 
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FIGURE 49. RELATION BETWEEN USER AND KERNEL STACKS 
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the newly created process andsets it in the blocked list of 
the special eventcount START. 

Mimeeerrarric Controller Create Eventcount (TCSCREATESEVC) 

This module is visible to the user via the "GATE". 

When invoked by an application process it creates the event- 
count specified by this process. TCSCREATESEVC is called with 
two input arguments, (a pointer to) the name of the eventcount 
to be created and the desired initial value, by the definition 
of eventcount [10] this value should always be zero. 

Upon invokation, TCSCREATESEVC locks the APT. It then 
calls TCSLOCATESEVC to determine whether or not the eventcount 
had already been created. This 1s to avoid making duplicate 
entries (Since each process which will use the eventcount must 
declare at least the name). If the eventcount had not previous- 
ly been created (viz., no entry is found in the Eventcount Table 
with the same name as given in the input argument) then an entry 
is made in the Eventcount Table. The name is copied into the 
Eventcount Table EVCSNAME field and the eventcount's current 
value (EVCSVALUE field) is initialized to the second input 
argument. Otherwise no entry is made. When the entry is made 
in the Eventcount Table the APTSPTR field is initialized to 
FFH (the nil pointer), meaning that there is no process in the 
blocked list corresponding to this eventcount (empty blocked 
list). 

The value of the variable EVENTS (see paragraph H3 of 


this chapter) is incremented by one each time an eventcount 
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is created. In this way the operating system keeps track of 
how many eventcounts are currently used. 

Finally, TCSCREATESEVC unlocks the APT and returns 
the program control to the calling procedure. 

eminence Controller Create Sequencer (TCSCREATESSEQ) 

This module is also visible to the user, via the 
"GATE". When invoked by an application process it creates 
a sequencer in exactly the same way that TCSCREATESEVC 
creates an eventcount. The only difference is that it accepts 
one input argument, (a pointer to) the name of the sequencer 
as defined by the user. The initial sequencer value is 
always zero. 

The operating system keeps track how many sequencers 
are currently used in the system by using the variable 
SEQUENCERS (see paragraph H9 of this chapter). 

13. Traffic Controller Read (TCSREAD) 

The TCSREAD module is also visible to the user, via 
the "GATE". It returns the current value of an eventcount to 
the calling process. It is called by one input argument, (a 
pointer to) the name of the specific eventcount. 

When invoked, TCSREAD locks the APT and then calls 
the TCSLOCATESEVC to obtain the index of this eventcount in 
the eventcount table (EVCSTABLE). Using this index, TCSREAD 
obtins the current value of the eventcount from the EVCSVALUE 
field of the EVCSTABLE and returns this value in the accumula- 


tor (AX) register. 
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Perot eee nreturning to the calling procedure it unlocks 
the APT. 
ime An Overall View Figure 
After finishing the detailed description of the ITC, 
system processes and TC, an overall view of the two-level 
scheduling and multiplexing technique is illustrated in 
Figure 50. This view 1s similar for each of the physical 
processors in the system. 

At the ITC level (LEVEL 1) the left most and right 
most virtual processor, e.g., VPSSTART and VPSEND are 
permanently bound to the MMGT and IDLE process respectively. 
They are in contention for physical resources (in the figure 
for the physical processors), but they are not in contention 
for user process scheduling. The remaining two central VP's 
are temporarily bound to supervisor processes (user or 
application processes) as determined each time by the 
TCSSCHEDULER. The criteron is that the highest priority 
process will be scheduled first. In the case when no super- 
visor process is ready, the TC invokes ITC IDLESVP (see 
paragraph I10) which loads an idle process on the VP. The 


idle process will actually run only when the VP to which it 


is permanently bound (VPSEND) is scheduled. This will happen 


only when all other VP's are waiting the occurrence of events 


or temporarily bound to idle processes (i.e., when there is 


"no work" for the specific physical processor). 
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BLOCKED SUPERVISOR PROCESSES READY 


99, [V9 


- 
LEVEL 2 


ITC | LEVEL 1 


HET) ss 
PROCESS 
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FIGURE 50. AN OVERALL VIEW FOR EACH PHYSICAL PROCESSOR 
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The ITC VPSCHEDULER schedules VP's on the physical 
processors. The criteron is that each time it schedules on 
the physical processor the highest priority "eligible" VP. 
Eligible in this design means ready or in the idle state, 
but with the preempt pending flag set. 

In this way the operating system supports multipro- 
gramming on each physical processor and also multiprocessing 
(concurrent processing) since there are several processors. 

The transitions of the processer among the 
"ready-blocked-run" states is controlled by the inter-process 
communication and synchronization mechanism and also the 
eCSSCHEDULER. 

The transitions of the VP's among the "idle-waiting- 
ready and run” states are controlled by the inter-virtual 
processor communication and synchronization mechanism and 
the VPSCHEDULER. 

Finally, the hardware interrupt structure is used for 


preemptive scheduling to support real-time processing. 


fo THE SUPERVISOR 
1. General Description 
In a general-purpose computer utility the "supervisor" 
provides the interface between application programs and the 
kernel of the operating system by supporting common services 
such as development tools (e.g., editors, compilers, assemblers, 


linkers, locaters, loaders), library functions, file system etc. 
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In the current implementation only one module is 
needed at the supervisor level, since all the above develop- 
ment tools are supported by the INTEL's MDS system (Micro- 
computer Development System). This module is written in 
assembly language and is called "Gate" or "Gatekeeper". 

There must exist a way to link each user (application) 
program with the operating system in order to have as a result 
the user (application) process shown in Figure 25. The Gate 
is this "actual linkage" and is constructed such that it is 
the only operating system module that the user has to link 
to his program in order to access kernel functions visible 
mo him. 

Zz. The Gate or Gatekeeper 

The Gate exists on the boundary between the kernel 
and supervisor levels of abstraction (see Figures 4, 5 and 9) 
and therefore is called a "software ring crossing mechanism". 
It is utilized to ensure that the kernel is "isolated" and 
"tamperproof". This module will be also important in the 
future if the system's internal security is considered. This 
structure is specifically designed to be compatible with the 
future version of the 8086 processor. 

The system services visible to the user are: MTCSAWAIT, 
TCSADVANCE, TCSTICKET, TCSCREATESEVC, TCSCREATESSEQ and TCSREAD. 
All these modules are related to the synchronization and 
communication mechanism. It is noted that the operating system 


never calls (execute the code of) these procedures. They are 
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called only by the user when the application programs need 
Synchronization support (viz., when an application program 
is partitioned into asynchronous interactive parts). 

The corresponding names for these procedures in the 
foe acre AWAIT, ADVANCE, TICKET, CREATSEVC, CREATESSEQ, and 
READ respectively. 

thie GATE contains the “public" declarations for these 
procedures and in this way allows the user to call these 
Operating system procedures in exactly the same way that any 
Other "external" procedure would be called. 

The advantage is that only the GATE (a very small 
module) is required to be linked and loaded with each user 
process and not the entire operating system. Furthermore, 
during system generation [19], the GATE can be located in 
exactly the same absolute address in memory for all of the 
processes loaded on a single microcomputer. The result is 
that the GATE segment loaded in with each process will be 
overlayed and the same copy will be shared. This minimizes 
the amount of physical memory used by the GATE. 

The GATE is a set of global procedures which the 
user programs can call directly. Each of the user accessible 
(visible) kernel functions is represented by one of these 
procedures. Actually they only set up the required para- 
meters and use a "trap" feature (INT instruction) to effect 
the call to the real procedure of the kernel. For example, 
when a user program calls AWAIT then the GATE using the 


Same parameters calls TCSAWAIT, and son on. 
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The GATE is written in assembly langauge because of 
the stack manipulation that must be done for parameters 
passing between PL/M 86 and ASM 86 (PL/M high level language 
and assembly language) and to invoke the "trap handler" in 
such a way to: 1) determine the correct kernel entry point 
(the proper procedure) to call, and 2) properly pass para- 
meters to the kernel procedures. 

The GATE consists of three small modules called GATE, 
trap handler and trap processes. When a GATE procedure is 
called by a user program the parameters are moved on the 
Stack and the GATE reaches the trap handler by an interrupt 
(e.g., an internal interrupt, or trap) using the INT 
instruction. The trap handler transfer program control to 
the corresponding trap process which in turn invokes the 
real kernel procedure with the same parameters passed on the 
stack by the user program. 

This has the effect of de-coupling the user from all 
the operating system modules below the Supervisor level. 

The software provided by the Gatekeeper has to perform 
additional functions upon the kernel entry and kernel exit, 
as shown in Figure 5l. 

Figure 52 tabulates the required format for all of the 
external procedure declarations that must be included in the 
user programs when invoking kernel functions. Of course, only 
the kernel functions actually invoked need to be externally 


declared by the user program. 
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Kernel Bry. 


1. Mask hardware preempt interrupts in the 
kernel. 


2. Save user domain registers in the user 
Stack (user domain). 


3. Switch from user to kernel domain (stack). 
4. Save user domain stack segment (SS) register 
and user stack pointer (SP) register in the 


kernel stack. 


5. Check arguments and invoke appropriate 
kernel entry point. 


Kernel Exit 


1. Check for virtual preempt interrupts (call 
CHECKSPREEMPT) when leaving the kernel 
(unmask virtual interrupt). 


2. Save kernel domain SS and SP registers in 
the kernel stack. 


3. Restore user domain SS and SP registers. 
4. Restore user domain registers. 
5. Unmask hardware interrupts. 


6. Return to the user process, execution point 
in the user domain. 


FIGURE 51. KERNEL ENTRY - KERNEL EXIT 
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Creating an Eventcount: 


CREATESEVC: PROCEDURE (EVENTCOUNT, VALUE) EXTERNAL; 
DELARE EVENTCOUNT POINTER, VALUE WORD; 
END; 


Creating a Sequencer: 
CREATESSEQ: PROCEDURE (SEQUENCER) EXTERNAL; 
DECLARE SEQUENCER POINTER; 
ED ; 
The Advance Operation: 
ADVANCE: PROCEDURE (EVENTCOUNT) EXTERNAL; 
DECLARE EVENTCOUNT POINTER; 
END; 
The Await Operation: 
AWAIT: PROCEDURE (EVENTCOUNT,VALUE) EXTERNAL; 
DECLARE EVENTCOUNT POINTER, 
VALUE WORD; 
END; 
The Ticket Operation: 


TICKET: PROCEDURE (SEQUENCER) BYTE EXTERNAL; 
DECLARE SEQUENCER POINTER; 
END ; 
The Read Operation: 
READ: PROCEDURE (EVENTCOUNT) BYTE EXTERNAL; 


DECLARE EVENTCOUNT POINTER; 
END ; 


FIGURE 52. KERNEL CALL EXTERNAL PROCEDURE DECLARATIONS 
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In J. Wasson thesis [8], there is a whole appendix 


(Appendix A) of 33 pages with programming instructions and 


examples how to use the synchronization mechanism and the 


Operating system. It is considered redundant to repeat these 


instructions. Instead, in Appendix A of this thesis will be 
incorporated several actual operating system test programs 


and their output. 
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V. CONCLUSIONS 


oe )6OCU RESULTS 

The principal goal of this thesis, the development of the 
kernel of a real-time, distributed operating system for a 
microcomputer based multiprocessor system was met. 

This operating system is hierarchically structured, 
layered in three loop free levels of abstraction, viz., the 
immer Traffic Controller, the Traffic Controller and the 
Supervisor, and fundamentally configuration independent. 

This verifiable loop free structure was demonstrated with 
EXAMPLE #6 in the Appendix A. 

Furthermore, at each level of this hierarchical structure 
the corresponding part of the operating system consists of a 
set of understandable modules whose interactions are clearly 
specified and strictly enforced. 

The result is a relatively small and easy to analyze 
operating system and this also was a principal goal. 

Since the kernel is small: (1) less memory is spent for 
its storage and (2) less processor time is spent in its 
execution. This advantage of less memory allows physical 
distribution of the kernel's code and data among the micro- 
computers and this distribution in turn helps to minimize 


system bus contention. 
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ween Other hand the layered modular structure provides 
the advantage of making it easy to debug, test and analyze, 
mmeuming COrrect operation and permitting an opportunity to 


increase performance by tuning. 


B. FOLLOW ON RESEARCH 

Although the kernel executes correctly, as shown in the 
examples of appendix A, before higher levels of abstraction 
are added to the system, a more formal test and evaluation 
plan should be developed. Once the kernel has been proven 
highly reliable then the follow on research is feasible for 
the reasons explained below. 

The existing stub for memory management process solves 
the two hardest problems of the memory management functions: 
(1) the interface with the kernel and (2) the needed inter- 
Virtual processor communication and synchronization. Both 
capabilities have been implemented and tested. 

The hard problem for adding I/O management is also the 
inter-virtual synchronization mechanism which exists and 
works correctly. For I/O management one more VP will be 
added on each physical processor permanently bound to the 
I/O process, in the same way as is done for MMGT and IDLE 
process. 

It is also possible to add file management (by dividing 
its functions among kernel and Supervisor). Finally, the 


process oriented structure of the operating system, the 
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separation of the address space of each process into user and 
kernel domain of execution and also the existence of the Gate 
lead automatically to the required structure for internal 
security. Additional segmentation hardware is needed to 
control the access (read, write) of the system's and user's 
subjects (viz., processes), to the system objects (viz., 
segments). The needed hardware will be available in the 


anticipated 8086 successor. 
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APPENDIX A 
SVoueiie Ss LES LENG 


This appendix incorporated six examples to demonstrate 
the use of the operating system and also to test the inter- 
process communication and synchronization mechanism, the 
inter-virtual processor communication and synchronization 
mechanism and the inter-real processor communication 
mechanism (used for preemptive scheduling and supported by 
the hardware interrupt structure). 

For each example, the input source code and the actual 
output to the printer are incorporated. 

Four of these test programs designed and implemented by 
the author and the remaining two by students working in the 
"Electro-Optics and Signal Processing Laboratory" of the 


Naval Postgraduate School. 
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EXAMPLE #1 


In this example there are two interactive processes 
running on a uniprocessor system under the operating system. 
This example demonstrates the multiprogramming capability 
and also the use of the inter-process communication and 
synchronization mechanism. 

In the input source code under the header EXAMPLE #1 
INPUT, there are enough comments for easy understanding of 
this example. Figures 53 and 54 are provided to illustrate 
the interleaved execution of.these two processes and how 
they interact using the synchronization mechanism. The 
output on the printer is also provided under the header 
EXAMPLE #1 OUTPUT. 

The variables A, B and C have been incorporated and 
are changed before and after entering the operating system 
kernel (e.g., when the process calls ADVANCE or AWAIT) 
to demonstrate that these values are correctly saved and 


restored from the per process stack. 
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EXAMPLE #1 INPUT 


y*® FILE 281.S88C Sanrseay 28 1321 

Beemer ol ILS: «86093 

Bee © (A.5,C.1) OBC, 
Myce iAy sits: 

Docume “SGi(*) BYTS INITIAL ( "ENTERING PROC #1. IT HAS SISHER 
weee(@=* STS INITIAL ( eeocal. ENTERING DELAY ~), 
Mereot=) ot re INITIAL (°EGeCUTINS me P20C#1 *), 
Meee) ev Te INITIAL (“SND Oe Us4OVSTAA SICH ~}, 
Seer TS [HITLIL (°CSPRENT VALJIE OF c= 7”), 
Meee ote ea ALLY poee 
Brea RP ALLY “2A” 

Degree CELTA(&) BYTE DATA( “DELTAZ‘), 
pevsGrni 6) SYTE DATA( “a@MEGA%”); 


Soames ColOSPAk4, SVCSTALSPARM) EXTERNAL; 
PEEVCSLESPAEM POINTER, 
SYCSVALS2A2™4 WORD; 


AEVANCZ: PSOCETORE (EVCSIDSPARM) EXTERNAL} 
JECLAPE SEVCSIDSPARM POINTER; 


QJTSSEAR: PROCZLIURE( CHAR); 
DECLARE CHAR BYTS 
LO WHILE (INPUT(QDAH) AND 21H) = 2; 
END} 
OUTPUT(OD3f) = CHAR; 


Bol Che. 


: ) BYTE SATA( °QLZZSSE7QSABLDEF” ); 
CALL DITSCHAR(ASCII(3H2(2,4) AND OFH)); 
CALL OUTSCHAP(ASCII(B AND JF2))3 
Eyes 
/RBRREREN seszz=> “A TN PRIGRAM SESSE TS FEN ERK EE / 


fe weroCete is ates HIGKER PRIORITY PROCESS */ 


CALL OCTSCHAR(CP); 
Gee QUISCEFR (LE); 
CALL OJTSCHAR(LF); 
bee = 2 70 335i 
BAMeEL, JUTSCEAR(MSS1(1))5 
END; 
vALL OUTSCRAR( 
CALL JUTSCHAR ( 


Se EOUNSC EAR ICS); 
mee CUTSCRAPILE); 
Gee OF TSCRAR’L=); 
Bop See ees 
Saou serene. “S52(1}); 
FNCS 
SenL JITSo hr (CR); 
GALL CUISCHAZ( LS); 


Zao 


eo. 





Pe NNITIAL VALUE OF EVENTS LELTA AND WM“EGA ABE 2 */ 
Seo eae AiT(@DELTaA,2)3 


ieee tae CALL STATEMENT [IS 2, GREATER THAN THE 
VALUS = 3, AWAIT KILL SUSPEND THE EXsCUITION OF THAT 
NGieesoetoo ANDO TPE SCEREDULSP WILL SCHECULE IRE EICHER 
Meee eee REMAINING PROCESSES. P80Ce#1l Wili GO TO THE 
Sele. t/ 


=<. C*m) 


4 


Oram HO 


Ga Orr. 


ffs 
Ta 
ba 
an 
a 


~~ 
+ 

tit "O -—— paty 

tri woo ares 


t1e3 


greet OUISCEAR(CR); 
mmm curSC HA? (L?); 
SM OUISCEAR (LZ); 
fom, = 3 10 133 
men OUTSCEAR(MSS3(I)); 


CALL OJTSCHAR(CR); 
SALL OUTSCHAR(L?); 


Geen JUTSCE&e (CR); 
Sree, OUJISCHAR(LI); 
Game OUISCHAR(LF); 
bem. — 0 10 Ze; 
San JULTsCeAR(MSS2(1))3 
END; 


CALL OUTSCHAR(CE); 

ae. OULSOHAR( LE); 

OOet = 0 TQ 229; 
Geek TIME( 229); 

onl; 

A = 03 

of) eae 

P= Ce; 


CALL AWAIT(AWYESA,1) 5 


/® SINCE 1 IS GREATER THAN PRESENT VALUE OF #MESA = @, PROCHI ¥/ 
J= WILL GO AGAIN TO TYE SLOCTED STATE AND SCHEDULER WILL SCUE-*/ 
Voweole PROC#<c ¥/ 


SeeLOIIESCHAR(CR); 
pee CULSORAS (LF); 
CALL QJUISCEAR(LY); 
CO Il = 2 [tO 153 


aE Le QUTSCZAR(“S33(1))s 


CALL QUISCHAR(CR)} 

Bier O7TSCHMR (LE); 

; SALL OUISCEAR(LF)} 

DO Il =2 70 22 
CALL OUTSCHAR(MS3E(1))3 

7ND} 

CALL DUTSCEAR(CH)} 

ie Our scusn(Le); 


DC i = 8 TO 2ad5 
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Crtteoe C21 EEK 


102 0) 63 
a ane! id 
» 
Oo coroong t+ 3 


cacar 
fe te 2 
tito 
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Peee tLe 2S2.SeC CR ee a nota 
PPSSMODUL: or 
mecuker’ (A,3,C) INTEGER, 
Peborl: 
Demmverees, “SGI (*)eayYTs INITIAL (°ENISPING PSICH#2. IT 3ZaS LOWER 
ore oY e INTUCAL ( BROCHZ. ENTFFING SELAY *), 
Wecots ) SYTE INITIAL UGICECTT ING IN PROCHE ~)., 
Sree LTP omeLLyY “208" 
SLIT anny “SLES 
SacUaes TILTa(s\ =VTE Pel agsstoks ), 
OeGeee) SYT& GAIA #éccay’); 
AWATD: PIOCELTIRE (EVCSILTSPARY ,SVCSVALSPASM) ZXTERNAL; 
CECLARE EVCSIDSPARM POINTER, 
TYCSVALSPAQM WORT; 
ae; 
ATTANCE: PROCEDURE (EVCSIDSPARY) EXTFRNAL; 
[TECLARE EVCSIDSPARM POINTER; 
END} 
QJTSCEAR: PPOCELYEE(CEHAR); 
TICLARE CHAR STE; 
CO #HILE CINPUT( ADA) AND 3148) = 23 
END} 
OUTPUT (@DS5R) = CHAR; 
310 
[PRR OB EE OF 2======) Mie ale ON Cee UG ee ae €=s22=2=2 TE OS HS TER AE 
PemeeoeGee [5 TYE LOV¥E2 PSIORITY PROCESS */ 
Bree OUTS CRAR(CR)3 
Pee Dur sOr AS (LF); 
CaEL QUISCEAR (LE); 
Bo I eke ae 
CALL euTocstk (“S31(1))4 
ENO? 
Se OULSCHAR(CR); 
Serre OUrSCEAR(LFE); 
A = 1233 
2 = £¥*12; 
C = Bra; 
CAEL ACVENCE( SLEUTA); 
/* ZVENT LELTA HAS NOW THE VALIE 1, SOT PROCHL CONTINUES SLEE 
/* JNTIIL TEE EVENT DELTA #AILL REACH TEE VALUE 2 *¥/ 
FALL OURS ORAROCR ) ; 
Se IJUISC RAP(L?); 
CMLL JUISCEAR (LZ); 
Pjet =eo To 22; 
GOEL CUTPeenwRMs 52(1)); 
aL > 
SADE OUISCEAR(CR); 


call OUISCRAR (Ls); 
LO 


i = @ TQ) ede; 


Be 


Oe ne 


PANG, = 7 


7 


\ 


vane 





Ent 

Meee. {AL VALUE OF SVENTS [eLta ane 
C = Crile: 

Sabl APVANCE(3LSLT2£) ; 

pomewenr JELTA REACRES VALUE 2, $0 ADVAN 
fees) Nib. Sat PPOCKeS FSO" 30N TD TEE 

omer PUGS” fil SCHEDULE TYE HIGHER Pe? 
Poeun OSR CASE SROCH#1). 


2 
7 
GaLL JUTSCEAR 
END; 
CALL 
CALL 


esac (l})3 


QUTSC SAR(CR)3 
JUISCEAR(L?)?3 

Geo JUTSC3AR (CR); 

CALL OQOUISCHAR(LSF); 

GeLL OCISCEAR(LI);3 

Memie= ¢ [9 22; 

Sal CUTSCHAR(YS32(1));} 

END; 


CALL OUTSCHAR(CR); 
CALL OUISCSAR(LF); 
DO f = 3 T0 223; 
CALL TIME(2&6); 
END; 
wee GtsO; 
ee= Ges 
A = 8*5; 
CALL ALCVANCE(2¢MEGA); 
PemrneeevENT SMEGA REACHES NOW TRE VALUE 1, SO ADVANCES WILL say) 
/*= A@ASS PROC#1 AND SET PROC#2 IN REALY STATE. [TEEN THE SCHE-*/ 
foeioaeeA tbo SOHELTILE Pa0ce#l (SINCE EBOTR PROCESSES ARE NOW IN*¥/ 
fomeee cee en Dk S:h8TS AND PRCCAL SAS FIGHER PRICRICY. ad 


Pee rOUTSCRAR(CR); 
CALL OUTSCHAR(LF);3 
CALL OUISCEAR(LF); 
EO iam 2 TO 133 
CALL OUTSCER&R( 


a ™ e 
vas @ 


CALL 


JSTSCHAR(C 2 
a Wise Cle 


SUrSG RRL 


)3 
)3 
CALL QUISCEAR(CR 
CALL OUTSCBAR(LF 
CALL OUTSCHAR(LFE 
DO I = 2 TO 22; 
CALL OUTSCEAR(MSTE 


R); 
F); 
3 
ry): 


CUTSCEARICFE); 
meorOUrSGe sR (Ls) § 


Mook 1) )3 
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ren, TiME(cSY); 
sal 


meee ACVANCE(2CELTA); 


eee ee 2eecuss NOW VaLJE 3, 3) PROCe#1l AN* EES AND IS SCEEOTLED */ 
~) 


5 
Moen IN. AND SO ON. ¥/ 


ee /* Jf P&SSsHOLuLe */ 
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EXAMPLE #1 OUTPUT 


ENTERING PROC#1. IT HAS HIGHER PRIORITY 
PROC#1. ENTERING DELAY 


ENTERING AWA TIT 


ENTERING PROC#2. IT HAS LOWER PRIORITY 


ENTERING ADVANCE 


PROC#2. ENTERING DELAY 


ENTERING ADVANCE 


EXECUTING IN PROC#I1 


PROC#1. ENTERING DELAY 


ENTERING AWATIT 


EXECUTING IN PROC#2 


PROC#2. ENTERING DELAY 


ENTERING ADVANCE 


EXECUTING IN PROC#1 


PROC#1. ENTERING DELAY 


CURRENT VALUE OF C = 03E8 


ENTERING AWA TIT 


EXECUTING IN PROC#2 


PROC#2. ENTERING DELAY 
ENTERING ADVANCE 
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iy hare 


‘ ‘ 





Deed 


at 





- 


EXECUTING IN PROC#1 


END OF DEMONSTRATION 
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PROC #1 PROC #2 |  ouTPUT 
Cee —aaerre a ee { 
OUTPUT MSG 1 (ENTERING PROC #l. IT 
[HAS HIGHER PRI 
B= 5 
Mp t 5 + 25 | 
o— A * 10 | 
OUTPUT MSG 2 IN READY 
STATE [PROC #1. ENTERING DELAY 
DELAY 
CALL AWAIT (DELTA, 2) (ENTERING AWAIT 
OUTPUT MSG 1 Coa PROC #2. IT 
{HAS LOWER PRI 
A= 10 
B=A¥* 10 | 
C=BtaA 
SLEEPING 
(BLOCK STATE) CALL ADVANCE (DELTA)$ ENTERING ADVANCE 
= bie PROC #2. ENTERING 
& 
aoe 1 OUTPUT MSG 2 ! DELAY 
DELAY | 
(e: ae Oe ee 0 I 
DELTA = 2|,. {CALL ADVANCE (DELTA)@4 ENTERING ADVANCE 
OUTPUT MSG 3 ane IN PROC #1 
PROC #1. ENTERING 
OUTPUT MSG 2 
U e | DELAY. 
DELAY 
A=cC IN READY | 
STATE r 
me A * 2 | 
A=c#* 5 i 


{CALL AWAIT (WMEGA, 1) | ENTERING AWAIT 





Y 


FIGURE 53. INTERLEAVED EXECUTION OF TWO PROCESSES 
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® | 


| 
OUTPUT MSG 3 EXECUTING IN PROC #2 






PROC #2. ENTERING 
DELAY DELAY 
C= C + 50 | 
BLOCK STATE B= C * 2 
: 


CALL ADVANCE (WMEGA)g ENTERING ADVANCE 


EXECUTING IN PROC #1 
PROC #1. ENTERING 


OUTPUT MSG 3 










OUTPUT MSG 2 DELAY. 
C = 03E8 


C= A/5 


ALL AWAIT(DELTA, 3) 


| 

DELAY READY STATE eae VALUE OF 
{ 
—— AWAIT 


EXECUTING IN PROC #2 
' proc #2. ENTERING 


OUTPUT MSG 3 





OUTPUT MSG 2 oma 
BLOCK STATE DELAY 
B=A* 2 


~ SGALL ADVANCE (DELTA ENTERING ADVANCE 


END OF PROC #2 
| 


OUTPUT MSG | EXECUTING IN PROC #1 
OUTPUT MSG 4 |! END OF DEMONSTRATION 
END OF PROC #1 | 





U 
S 
: | 
FIGURE 54. INTERLEAVED EXECUTION OF TWO PROCESSES 
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EXAMPLE #2 


In this example there are two interactive processes 
running on a uniprocessor under the operating system. These 
two processes simulate the image processing processes CLUTTER 
SUPPRESION AND FILTER DESIGN. The data comes into the micro- 
computer as frames of images and an extensive use of the 
synchronization mechanism is required. 

Following the comments in the input source code under 
the header EXAMPLE #2 INPUT and the output messages under 
the header EXAMPLE #2 OUTPUT, it is possible to follow the 


interleaving execution and interaction of these two processes. 
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/* 
So ees MODULS: 


DECSARE 
DesLaPs 


© 
oes 


a ee 
wt o2 


G36)?G2 Gt 


.< 


EXAMPLE #2 INPUT 


2 SLITER ALLY 


INITIAL 


eee Nee a 


INITIAL 
EAT ELAL 


E 
C 
LF LITERALLY 
Y 


“OAH 5 


Bie DATAXK CSUSP2"); 
BYTE DATS(°=LDES%*); 


peace. 
CHL. 


—_ 


Dilla eiOhy sLNTONCLULT =n SuUPPERSSION ~ 
WAIT FOR DATA REALY : 
OPRTORMING CLUTTER SUPPRESSICN ON FPAME: 

ADVANCE FILTER DESIGN EVENTCOUNT *)3 


AWAITS PPICEDURE(EVCSIDSPARM, SVCSVALSPARM) EXTERNAL; 


CPOCLA 
£ND; 
ALTVANCSs 


IND; 


SULSCEAR: 


DECLARES 


RE sVCSIDSPARM 


POINSSH, 


SVCSVALSPARM WORDS 


PROCELURE(EVCSILSPARM) EXTERNAL; 


PROCEDJRE(CHAR); 


DECLAPE CHAR BYTE; 
ILE (INPOT(Q@DAH) AND @1H) = 23 END; 
JUTPUT (2094) 


DO WE 
oND; 


JUTSEEYs 


SALL 
IND; 


IT = 4} 


= CHAR; 


PROCELURE(E); 
LECLARE 3 3YTE; 
DECLARE ASCII(*) BYTE DATA (°2123455739ABCDEF 1; 
CALL DJUTSCHAR(ASCII(SER(B,4) AND 2FH)); 


CALL JOTSCHAR(LE); 


DO 2 
oNT; 


= 2 T0 46; 
CALL OJTSCHAR(MS31(Z))3 


CALL JUISCHAR(C3); 
CALL JOTSCRAR(L?); 
CALL JUTSCHAR(LE); 
(I <= $4); 


CALL JUTSCHAR(LY); 


DO WHILS 


Oe | 7A 


é TO 46; 


SVCSIDSPARM SOINTSER; 


JUTSCHAR(ASCII(3 AND OFEH)); 


CALL OUTSCRAR(MSS2(7));3 


END; 


GRCL QITSCHAR( CS); 


GALL JUTSCHAP( 
CALL QJUTSCEAR( 


Ca); 
LF); 
L?)3 
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rope WAL St SCsuPP, 1); 


f= if + 1; 


aa peoo To cene (lL =)5 
Rome coc. 6) 45; 

PMB OuUISCTAR<. YSS3(Z))3 
END; 
Greeny DU TSESY (1%; 
eu CUTS eae (Cc? ); 
SeLL JUTSCHAR(L=); 
Cece DU LS CH Mees )5 
Be 2 = 2 10 222; 

Pxyuu SiMe (Zsa); 
NTs 


CAGL SU TSCHAR( LF); 
D002 = 2 10 46; 
CALL OUTSCHAR(MS34(2Z))3 
END; 
CALL JUTSCHAR(CR)$ 
CALL JITSCHAR(LF); 
Cece SU RSCHAR( LF); 


CALL ADVANCE(QPFLDES ); 
END; /* #BILE */ 
Beas) /* MODULE **/ 
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La J 


€ 74 <1 


Se 


meoer lULEs [Q; 
Poowee [Er es 
Poousls Cee ere ee thLy “cru” , 
- ¢ 2 eo 
LF LilsRaLey dad; 


BooARE 2 2YTE; 


RYTE CATA( °CSUPPS”) 


CEOLARE CSUPP(3) : 
Sen Smee DATA( “FLDSS%*); 


Peousiae® Lus 


CLARE 

Seem) Syms INITIAL (“PROC#S. INITIAL ENISY INTO FILIER CESIGN *), 
Beet’ BYTE INITIAL (°PROC#2. AWAIT FO8 DATA READY 7), 

S33(*) 3YTE INITIAL (°PROCH#S. PERFORMING FILIER LESIGN ON FRAME: 
S34(*) BYTE INITIAL (°PROCKH2. ADVANCES CLUTTISR SUPPRESSICN EVENTCOUNT 


iT: PRICELURE(EVCSIDSPAR™“,2VCSVALSPARM) SXTERNAL; 
DECLARES SVCSIDSPARM POINTER, 
EVCSVALSPARM WORD; 


ADVANCES: PROCEDORE(SVCSIDSPARM) EXTERNAL; 
DECLAPE EVCSIDSPARM POINTER; 
END; 


OUTSCHAR: PROCEDCRE(CHAR); 
wECLAPF CEAR BYTE; 
[TO WHILE (INPUT(ZITAE) AND 31K) = 8; END; 
DUTSUT(av8h) = CHAR; 


X: PROCELIRE(3); 
LARE B 3YTE, 
ASCII(*) BYTE DATA ( ‘’312345E7SSABCDEF”); 
CALL JUTSCHAR(ASCII(SHR(B,4) ANE ZFS)); 
CALL QUTSCHAR(ASCII(3 AND 3FH)); 
END; 


2 taf 


T= @3 


DO Z = 23 T0 49; 
CALL DUTSCHAR(MSS1(Z))3 
ENT} 
CALL 2UTSCRA2(CR); 
CALL JUTSCEAR(L=)3 
SALL JUISCHAR(L?)3 


DC WHILE (I <= 84); 


CALL SUTSCHAP(LE); 
Bor? = € 10 29; 
CALL OUTSCHAR(MS32(2Z));5 
END; 
eeepmorscCewR( CR); 
Suse reotAS( LF); 
CALL JUTSCHAR( LI); 


SALL AWAIT(@FLDES .I); 


aoe 





f= it + 1; 


Goma = @ 720 200; 
Cell TiMk (ese); 


to | 
ae 
tJ 
= 


CALL JUTSCESR( LF); 
[2 Z = @ P9 423 


CALL JUTSHEX(I); 

Skt Gecursceare (CR); 
Gace DUTSECRAP( LS); 
Gms JUTSCHAaT ES); 


emcee, JUTSCRARI LE); 
Hoe, = 2 TO 46; 
CALL OUTSCRAR(MS34(Z));3 
END; 
CELL JUTSCUAR(C2);3 
GALL JUTSCHAZ(LI); 
Sa JUISCHAR( LF); 


CALL ADVANCE(@CSJPP); 


END; /#* #KILE */ 


/*4O0DCLE */ 
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EXAMPLE +2 OUTPUT 


PROC#1. INITIAL ENTRY INTO CLUTTER SUPPRESSION 


PROC#1. WAIT FOR DATA READY 


ENTERING =awWA TL FT 


PROC#1. PERFORMING CLUTTER SUPPRESSION ON FRAME: 


PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. WAIT FOR DATA READY 


ENTERING AWAIT 


PROC#2. INITIAL ENTRY INTO FILTER DESIGN 
PROC#2. AWAIT FOR DATA READY 

ENTERING AWAIT 

PROC#2. PERFORMING FILTER DESIGN ON FRAME: 01 


PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. PERFORMING CLUTTER SUPPRESSION ON FRAME: 


PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. WAIT FOR DATA READY 


ENTERING AWAIT 


PROC#2. AWAIT FOR DATA READY 


ENTERING AWAIT 
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PROC#2. PERFORMING FILTER DESIGN ON FRAME: 02 


PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. PERFORMING CLUTTER SUPPRESSION ON FRAME: 


PROC#I1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. WAIT FOR DATA READY 


ENTERING AWAIT 


PROC#2. AWAIT FOR DATA READY 


ENTERING AWAIT 


PROC#2. PERFORMING FILTER DESIGN ON FRAME: 03 


PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. PERFORMING CLUTTER SUPPRESSION ON FRAME: 


PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. WAIT FOR DATA READY 


ENTERING AWA TIT 


PROC#2. AWAIT FOR DATA READY 


ENTERING AWAIT 


PROC#2. PERFORMING FILTER DESIGN ON FRAME: 04 


PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


235 


03 


04 





ENTERING ADVANCE 


PROC#!1. PERFORMING CLUTTER SUPPRESSION ON FRAME: 


PROC#!1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING ADVANCE 


PROC#!1. WAIT FOR DATA READY 


ENTERING AWAIT 


PROC#2. AWAIT FOR DATA READY 


ENTERING AWAIT 


PROC#2. PERFORMING FILTER DESIGN ON FRAME: 05 


PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. PERFORMING CLUTTER SUPPRESSION ON FRAME: 


PROC#1!1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. WAIT FOR DATA READY 


ENTERING AWATIT 


PROC#2. AWAIT FOR DATA READY 


ENTERING AWAIT 


PROC#2. PERFORMING FILTER DESIGN ON FRAME: 06 


PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING ADVANCE 


PROC#1!1. PERFORMING CLUTTER SUPPRESSION ON FRAME: 
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05 


06 


07 





: 


PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. WAIT FOR DATA READY 


ENTERING AWATIT 


PROC#2. AWAIT FOR DATA READY 


ENTERING AWAIT 


PROC#2. PERFORMING FILTER DESIGN ON FRAME: 07 


PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. PERFORMING CLUTTER SUPPRESSION ON FRAME: 


PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. WAIT FOR DATA READY 


ENTER ING AWAT T 


PROC#2. AWAIT FOR DATA READY 


ENTERING AWATIT 


PROC#2. PERFORMING FILTER DESIGN ON FRAME: 08 


PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING ADVANCE 


PROC#1. PERFORMING CLUTTER SUPPRESSION ON FRAME: 


PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING ADVANCE 


° 3°] 


08 
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EXAMPLE #3 


The input source code for this example is exactly the 
same as for the previous example. The difference is the output. 
The output under the header EXAMPLE #3 OUTPUT has more output 
messages. In fact in every module of the operating system 
has been incorporated at least one output message as shown 
mrermiaure 55, 

In this way the debugging and checking becomes easier. 

Also it is possible to follow the flow of program control 
between several modules of the operating system. 

The higher priority process is PROC#1l (CLUTTER SUPPRESSION) 
with priority 40 and the lower priority is PROC#2 (FILTER 
DESIGN) with priority 41. 

The address space descriptor for the first process (the 
base of its "per process stack") is equal to 6000H(this 
appears as 600 because of INTEL's monitor convention), for the 


second it is 7000H and for the idle process it is 5000. 
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LEVEL 


TC 


aC 


PneGURIS 55. 


MODULE 
Canc a/LRTINT 


ITCSRETSVP 


ITCSLOADSVP 


CHECKSPREEMPT 


GETWORK 


RUNSTHISSVP 


ITCSSENDSPREEMPT 
LOCKVPM 
UNLOCKVPM 


REY THISV? 


TCSSCHEDULER 
TCSLOCATESEVC 
TCSAWAIT 
TCSADVANCE 


TCSPESHANDLER 


OUTPUT MESSAGES OF THE OPERATING SYSTEM'S MODULES 
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OUTPUT MESSAGE 
ENT RRUING CHECK IRON 


ENTERING ITCSRETSINT 
RUNNINGSVPSID = 


ENTERING ITCSLOADSVP 
LOADING VP NUMBER: 
PRIORITY FOR THIS VP is: 
NEWeOB Rl Ok in tomy © slo 
ENTERING CHECKPREEMPT 


ENTERING GETWORK 
SELECTEDSDBR = 


ENTERING RUNTHISVP 
SET VP TO RUNNING: VP = 


ENTERING ITCSSEND$PREEMPT 
ENTERING LOCKVPM 
ENTERING UNLOCKVPM 


ENTERING RDYTHISVP 
SETUP TOPREADY: VP = 


ENTERING TCSSCHEDULER 
ENTERING TCSLOCATESEVC 
ENTERING AWAIT 
ENTERING ADVANCE 


ENTERING TCSPESHANDLER 





EXAMPLE 


ENTERING CHECKVIRTINT 
ENTERING LOCKVPM 
ENTERING RDYTHISVP 
ENTERING ITCSRETSVP 
RUNNINGSVPS$ID 
SEleve TO READY: VP 
ENTERING GETWORK 
SELECTED$DBR 
ENTERING RUNTHISVP 
SET VP TO RUNNING: VP 


ENTERING 
ENTERING 
ENTERING 


ENTERING 
ENTERING 
ENTERING 


ENTERING 
ENTERING 


UNLOCKVPM 
CHECKPREEMPT 
ITCSRETSVP 
RUNNINGSVP$ID 
TC$PESHANDLER 
TC$ SCHEDULER 
ITCSRETSVP 
RUNNINGSVP$ID 
ITCS$LOAD$VP 
ITCSRETSVP 
RUNNINGSVP$ID 


LOADING VP NUMBER: 
PRI@RITY FOR THIS VP IS: 
NEW DBR FOR THIS VP IS: 
ENTERING GETWORK 
SELECTEDSDBR 
ENTERING RUNTHISVP 
SET VP TO RUNNING: VP 
ENTERING UNLOCKVFM 
ENTERING CHECKPREEMPT 
ENTERING ITCS$RETSVP 
RUNNINGSVPSID 


PROC#1. 


PROC#1. 


ENTERING 
ENTERING 
ENTERING 
ENTERING 
ENTERING 


ENTERING 
ENTERING 


AWAIT 


ITCSRETS$VP 
RUNNINGSVP$ID 
TCSLOCATESEVC 
TC$SCHEDULER 
ITCSRETS$VP 
RUNNINGS$SVPSID 
ITCSLOADSVP 
ITCSRETSVP 
RUNNINGSVPS$ID 


LOADING VP NUMBER: 

PRIORITY FOR THIS VP IS: 

NEW DBR FOR THIS VP IS: 
ENTERING GETWORK 

SELECTED $DBR 

ENTERING RUNTHISVP 

SET VP TO RUNNING: 


VP = 


PROC#1. 


#3 OUTPUT 


00 
00 


0500 


01 


01 


01 


01 
01 
40 
0600 
0600 


01 


01 


INITIAL ENTRY INTO CLUTTER SUPPRESSION 


WAIT FOR DATA READY 


01 


01 


PERFORMING CLUTTER SUPPRESSION ON FRAME: 
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PROC#1. 
ENTERING 


ENTERING 
ENTERING 


ENTERING 
ENTERING 


ENTERING 
ENTER ING 


ADVANCE FILTER DESIGN EVENTCOUNT 


ADVANCE 


TCSLOCATESEVC 
ITCSRETSVP 
RUNNINGSVPS$ID 
TC$ SCHEDULER 
ITCSRETSVP 
RUNNINGS$VP$ID 
ITC$LOADS$VP 
ITCSRETSVP 
RUNNINGSVPS$ID 


O01 


iT] 
© 
— 


iT} 
So 
_ 


LOADING VP NUMBER: O01 
PRIORITY FOR THIS VP IS: 40 
NEW DBR FOR THIS VP IS: 0600 
ENTERING GETWORK 


ENTERING 


SELECTEDSDBR 
RUNTHI SVP 


ub 
© 
oO 
oS 
© 


SET VP TO RUNNING: VP = 01 


PROC#1. WAIT FOR DATA READY 


ENTERING 
ENTERING 
ENTERING 
ENTERING 
ENTERING 


ENTERING 
ENTERING 


AWATT 


ITCSRETSVP 
RUNNINGSVPS$ID 
TCSLOCATESEVC 
TC $ SCHEDULER 
ITCSRETSVP 
RUNNINGS$VPSID 
ITCSLOADS$VP 
ITCSRETSVP 
RUNNINGSVPSID 


01 


u 


iT) 
© 
m 


i 
oO 
_ 


LOADING VP NUMBER: 01 
PRIORITY FOR THIS VP IS: 41 
NEW DBR FOR THIS VP IS: 0700 
ENTERING GETWORK 


ENTERING 


SET VP TO RUNNING: VP 


SELECTEDSDBR 
RUNTHI SVP 


il 
oO 
«J 
Oo 
Can | 


Ml 
So 
— 


ENTERING UNLOCKVFM 
ENTERING CHECKPREEMPT 


ENTERING 


PROC#2. 


ITCSRETSVP 
RUNNINGSVPSID = 01 


INITIAL ENTRY INTO FILTER DESIGN 


PROC#2. AWAIT FOR DATA READY 


ENTERING 
ENTERING 
ENTERING 
ENTERING 
ENTERING 


ENTERING 
ENTERING 


AWA TIT 


ITCSRETSVP 
RUNNINGS VP$ID 
TCSLOCATESEVC 
TC$ SCHEDULER 
ITCSRETSVP 
RUNNINGS$VP$ID 
ITCSLOADS$VP 
ITCSRETSVP 
RUNN ING$VPS$ID 


01 


u 


01 


01 


iT) 


LOADING VP NUMBER: 01 
PRIORITY FOR THIS VP IS: 41 
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NEW DBR FOR THIS VP IS: 0700 
ENTERING GETWORK 
SELECTEDSDBR = 0700 


ENTERING RUNTHISVP 
SET VP TO RUNNING: VP = 01 


PROC#2. PERFORMING FILTER DESIGN ON FRAME: 01 


PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING 


ENTERING 
ENTERING 
ENTERING 
ENTER ING 


ENTERING 
ENTERING 


ENTER ING 
ENTERING 


ADVANCE 


TCSLOCATESEVC 
ITC$ SEND$ PREEMPT 
ITC$ SEND$ PREEMPT 
ITCSRETSVP 
RUNNINGS$VP$ ID 
TC$ SCHEDULER 
ITCSRETSVP 
RUNNINGS$VP$ID 
ITC$LOAD$ VP 
ITCS$RETSVP 
RUNNINGSVP$ID 


ul 


i 


Ml 


LOADING VP NUMBER: 
PRIORITY FOR THIS VP IS: 
NEW DBR FOR THIS VP IS: 


01 


ENTERING GETWORK 
SELECTED$DBR 
ENTERING RUNTHISVP 
SET VP TO RUNNING: VP = 01 


il 
f=) 
Oo 
oS 
fm) 


PROC#1. 


PROC#1. 


ENTERING 


ENTERING 
ENTERING 


ENTERING 
ENTERING 


ENTERING 
ENTERING 


ADVANCE 


TCS$SLOCATESEVC 
ITCSRETSVP 
RUNN INGSVP $ID 
TC$ SCHEDULER 
ITCSRETSVP 
RUNNINGSVPSID 
ITCSLOADSVP 
ITCSRETSVP 
RUNNINGSVPSID = 


i} 


it} 


LOADING VP NUMBER: 
PRIORITY FOR THIS VP IS: 
NEW DBR FOR THIS VP IS: 


PERFORMING CLUTTER SUPPRESSION ON FRAME: 


ADVANCE FILTER DESIGN EVENTCOUNT 


01 


ENTERING GETWORK 
SELECTEDSDBR 
ENTERING RUNTHISVP 
SET VP TO RUNNING: VP 


it} 
=) 
oO 
oS 
(>) 


ul 
oO 
Ea 


PROC#1. WAIT FOR DATA READY 


ENTERING AWAIT 


ENTERING ITCSRETSVP 


RUNNINGSVPS$ID = 01 
ENTERING TCSLOCATESEVC 
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ENTERING ITCSSCHEDULER 


ENTERING ITCSRET$VP 
RUNNINGSVP$ID 
ENTERING ITCSLOADS$VP 
ENTERING ITCSRETS$VP 
RUNNINGSVPSID 
LOADING VP NUMBER: 01 
PREORITY FOR THIS VP IS: 41 
NEW DBR FOR THIS VP IS: 0700 
ENTERING GETWORK 
SELECTEDSDBR 
ENTERING RUNTHISVP 
SET VP TO RUNNING: VP = 01 


il 
Oo 
— 


il 
oO 
— 


i) 
fo] 
«Jj 
© 
© 


PROC#2. AWAIT FOR DATA READY 


ENTERING . AWAIT 


ENTERING ITCSRETSVP 


RUNNINGSVPSID = 01 
ENTERING TCSLOCATESEVC 
ENTERING TC$SCHEDULER 
ENTERING ITCSRETSVP 

RUNNINGSVPS$ID = 01 


ENTERING ITCSLOAD$VP 
ENTERING ITCSRETS$VP 
RUNNINGSVPS$ID 
LOADING VP NUMBER: 01 
PRIORITY FOR THIS VP IS: 41 
NEW DBR FOR THIS VP IS: 0700 
ENTERING GETWORK 
SELECTEDSDBR 
ENTERING RUNTHISVP 
SET VP TO RUNNING: VP = 01 


Ul} 
© 
ms 


il 
o 
“J 
Oo 
oO 


PROC#2. PERFORMING FILTER DESIGN ON FRAME: 02 


PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING ADVANCE 


ENTERING TCSLOCATESEVC 
ENTERING ITCSSEND$PREEMPT 
ENTERING ITCSSEND$PREEVMPT 
ENTERING ITCSRET$VP 
RUNNINGSVPSID 
ENTERING TCS$SCHEDULER 
ENTERING ITCSRETSVP 
RUNNINGSVPS$ID 
ENTERING ITCSLOADSVP 
ENTERING ITCSRETSVP 
RUNNINGSVPSID = 0O1 
LOADING VP NUMBER: 01 
PRIORITY FOR THIS VP IS: 40 
NEW DBR FOR THIS VP IS: 0600 
ENTERING GETWORK 


01 


it 


01 


SELECTED$DBR = 0600 
ENTERING RUNTHISVP | 
SET VP TO RUNNING: VP = 01 


PROC#1. PERFORMING CLUTTER SUPPRESSION ON FRAME: 03 
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EXAMPLE #4 


This example was designed and implemented by Kurt 
Holmquist for testing purposes of the operating system, 
and consist of five processes running on a uniprocessor 
system under the operating system. 

In the following pages are included the input source 
code under the header EXAMPLE #4 INPUT and the output of 
the microcomputer directly to the printer under the header 


EXAMPLE #4 OUTPUT. 
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EXAMPLE #4 INPUT 


fem oes TO72LS sc1tainas 4 oroeran fron waieta 
Tulticsle rrocesses can 92 fFanerated by 
eae 7 > Sydourodization an? schedvuliaz2 
meee ti ols. fess aug7csr of orocesses 


32> seated is the valte aux mene). 


reaiz 


ar 


Poet1 Paoc: 


sts wie fe es ed 


[RA SAS Ee 


20% 


BUbeEial proce tpt 


dis ea as ee 


Bemeepedet: rROCEDISE (valu2) EFTESNAL; 
CeCLaxg= value w#ORT; 

SONI 9 

a2ai chars PRICELURE EYTE EXTERNAL; 

eNT; 

“assaz2: PPOCEDUFE (mrese¢_aii) SXTERNAL; 
CUECLARE nesz_aii POINTER; 

END; 

Await: PPOCEDORS (2vent_nam2,count) EXTERNAL; 
DECLARE avent_nane POINTER, 

eoulat WORT; 

=N)D;5 

Advance: PROCELUFE (ev2ant_nan2) EXTERNAL; 
PECLARE esvent_aane POINTER; 

SND; 

fereere Evant count ieslaration  ***2*% / 


aivance_next ( 


Ss) Slo> DATA ( - ADNK TS); 


{8S Magsz3e3 ani variable isaclarations  ***#**/ 
NeCLaee 
7 orun (*) BYTE INITIAL (2 ona ZAB,SAH, “RUNNING PROCESS #°), 
o1un (aye BYTE eWNI TIAL (~ DBR = °,8), 
m aiva (*) EYTE INITIAL aR OL ' 

Gir eA Reto .GALG ADVANOS.. 4,2), 
™ awai (*) BYTE INITIAL (2DH,2AH, ~ . ae 

HIT A REY TD CALL AWAIT 22). 
(awaitel couat, ss_reg, ae oe WORD, 


i *ORD INITIAL (8), cha BYTE; 
Mecretc iun_proc LITERALLY ‘5°; 
DECLARE ENTRY LAEEL PPBLIC; 
/*® Frogran for any tunber of processes to execute oye 
ENTHY: oO WHILE 1; 
/*® e#ac2 process iientifies itsalf by readirege tie 
valu2 of the stack saerent rerister (DSR). a 
ss cee = STACTTASE; 
prozass = SEE(ss_rez, 4) AND 3FR; 
onan (€) = LOW (oros2ss) + JZOE} 








/* 


/* 


L Message (ar _eprun) 
Dimedoetidexe (ss re 


uy ws 


CaLL “essage (3r_adva); 


Sata eee st. caar; jes? Caynoar? L2cut co stes 
toroucn ths vrocriam ty 
3222uS2 ta2 Last orot]ss on $22 load list 148 lower 
Porcthiametolc all the ctnsrs, it has a sliently different 
prozran ssjuencs. for the last ogrocess only, tne orocess 
switca will take plas? wien tne call to Aivance is nade. */ 


tr 
Lee | 
ro 
“3 
Oo 


cess = nun_pros TSEN 50; 
CALL Advance (@aivance aext); 


Bie roOcesses Srcent tae last 922 on tae load list 
arecute tae following. af, 


Advaase tae event count */ 
CALL Aavanc2 (@advance_ next); 


CALL “essage (@mr_awai); 


aweit>i coun = ((1-1)/5 + 1)*53 

CALL Await (Gadvance_aext,awaited count); 
The surrently runnine process will become dlockei 
at this voint ani another proces vill begin ruaaliag. 
moeaea orecess waica 1425 previously blockei itsels 
bering running again, the entry point will be here 
ani tae fsllowinzg call will ieternine the procé’ss 
Swrtoo tire. ~/ 

ENG; 


END$ 
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RUNN ING 


RUNNING 


RUNNING 


~ RUNNING 


RUNNING 


RUNNING 


RUNNING 


RUNNING 


RUNN ING 


RUNNING 


RUNN ING 


RUNNING 


RUNN ING 


RUNN ING 


RUNNING 


EXAMPLE 
PROCESS #1 DBR 
PROCESS #2 DBR 
PROCESS #3 DBR 
PROCESS #4 DBR 
PROCESS #5 DBR 
PROCESS #1 DBR 
PROCESS #2 DBR 
PROCESS #3 DBR 
PROCESS #4 DBR 
PROCESS #5 DBR 
PROCESS #1 DBR 
PROCESS #2 DBR 
PROCESS #3 DBR 
PROCESS #4 DBR 
PROCESS #5 DBR 


#4 OUTPUT 


= 0710 


= 0720 


= 0730 


= 0740 


= 0750 


= 0710 


= 0720 


= 0730 


= 0740 


= 0750 


= 0710 


= 0720 


= 0730 


= 0740 


= 0750 
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HIT 
BIT 


HiT 
olay 


LIL OY 
Hie 


Hit 
mi 


bo) Gal 


Hie 
Je EI 


1 CGY 
HIT 


Hie 
Hi 


Hie 
oO ay 


Fe 


HiT 
Hit 


Bit 
Hie 


HiT 
Hi 


Bick 
HiT 


Hid 


KEY 


KEY 
KEY 


CALL 
CALL 


TO CALL 
TO CALL 


TO CALL 
TO CALL 


CALL 
CALL 


CALL 


CALL 
CALL 


CALL 
CALL 


CALL 
CALL 


CALL 
CALL 


CALL 


CALL 
CALL 


CALL 
CALL 


CALL 


TO CALL 


CALL 
CALL 


CALL 


"ADVANCE". 
"AWAIT". 


"ADVANCE". 
"AWAIT « 


"ADVANCE". 
"AWAIT". 


"ADVANCE". 
"AWAIT". 


"ADVANCE". 


"ADVANCE". 
"AWAIT". 


"ADVANCE". 
"AWAIT". 


"ADVANCE”. 
"AWAIT". 


"ADVANCE". 
"AWAIT". 


“ADVANCE”. 


"ADVANCE". 
"AWAIT". 


"ADVANCE”. 
"AWAIT". 


"ADVANCE". 
"AWAIT". 


"ADVANCE". 
"AWAIT". 


"ADVANCE". 





EXAMPLE #5 


This example was designed and implemented by the following 
Students of Naval Postgraduate School: 

LT Kenneth Webb 

LCDR Leo Schnieder 

LT Antony Christian 
in partial fullfillment (as a project) of the requirements of 
the course CS 3550. It can be used to test the synchronization 
and communication mechanisms of the operating system. 

In Figure 56 is shown the interactions of five processes: 
I/O CONTROLLER, ID-POSIT, CORRELATION, TRACK and DISPLAY. Also 
shown are five shared buffers: SENSBF, SENSDR, ACTIVE-BUFFER, 
OUTPUT TABLE and TRACK TABLE residing in the system's global 
memory while the processes code and data are located into the 
microcomputer's local (on board) memory. For example, the 
shared buffer SENSBF is used by the I/O CONTROLLER and ID-POSIT 
processes’ and so on. 

Flow of information into and out of the various processes 
and buffers is indicated in Figure 56 by the direction of the 
arrows. Eventcounts are shown between the processes. 

The details about this project will not be incorporated 
here since these can be extracted from the following input 
source code, under the header EXAMPLE #5 INPUT. The output 
to the printer follows the input source code, under the 


header EXAMPLE #5 OUTPUT. 
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TRACK 


TABLE 


FIGURE 56. 


WAG, 
CONT ROLLER 


SENSBF 


if D) 8 12t@) Sean 


SENSDR 
PBeECS 


CORRELATION 


ACTIVE- 


ACBUF TABAC BURGER 


TRACK 


OUTEUT 


OTRDN TABLE 


DeDAT 


DISPRAY 


AN EXAMPLE OF FIVE INTERACTIVE PROCESSES 
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te IE yey i 


Pega? 5 
Dao LARE 
Pealare 
eae Lae = 


DECLAEE 

met LARE 
DECLARE 
Pao LARS 


DECLARE 
CEcLARE 
DECLAPEc 
CPECLARE 
CECLARE 
GacLAPs 
DECLARE 
CEGLARE 
DSCLARE 
DECLAPE 
CECLARE 


AWAIT: 
c 


PESCEDOSE (EVCSIDSPARM, 
ESLARE 2VCSILTSPARM POINTER; 


EXAMPLE i) TNE OT 


Sa 


AN SES SPUN 0 Faller a 


EoLNN ING / 


SONS * / 


wewOe Oe TiITLTAL( 2); 

merece) SYTHE MORTA (°IDPISZ’); 
mepoce(e) Sirs DATA (“IDPISS”); 
mrece (2) et Temata (° TOP QRS” +3 


memset Ato) SY TE DATA( “TGTSDATAS’ ); 
PUSSOSETSSTALT(15) BYTE DATW( “LDSPOSITSSTARIZ”); 
DeeemeER INITIAL (2); 

SENSEI? (20) STRICTIRE (INFO(1S) 2YTE, 
SLAGS? BYTE) SXTIERNAL; 

AESET LITERALLY °9OH’; 

Pee SORT initial (te); 

(Jeb SGS2°SINS) INISGER; 

(XSSENS, YSSENS, RANGE) INTEGER; 
2UFFER(13) INTESER; 

(BNGSMULTSPTP, POSITSPIR) SOINTER; 
SENSSNUMI INTEGER SYTERNAL;} 

(XSTGD, YSTST) INPEGER EXTERNAL; 

TY“S1 WORD EXTERNAL; 

(PNGS“OLT BASED BNGSMULISPTR) (2) INTEGER; 
(POSIT BASED POSITSPIR)(2) INTEGER; 


TYME WORDT, 


SVCSVALSPARM) EXTERNAL; 


DECLAPE SVCSVALSPARM #ORD; 
END AWAIT; 


MEVANCEs 
DECLARE EVCSIDSPARM POINTER; 


PROCELURE (EVCSIDSPARM) EXTERNAL; 


END ADVANCE; 


INSANALYZZEFs PSOCEDIRE (BEAPING) POINTER EXTERNAL; 


DECLARE BEARING INTEGER; 


END SNGANALYZER; 


toe gr OS 1 


T: PRICEDUSE (XSBASE, Y$BASE, XSCOMP, 
EXTERNAL; 
DECLAPE (XSBASE,YSBASE, X$COM?, FYSCOMP, RNS) INTEGER; 


YSCOMP, FNG) POINTER 


£ND TGTSPOSIT: 


writ2: procedure (ptr) axteraal; 
Leclareptr pointer; 


acs 


INITV2: 


EN 


PROCELJRE EXTERNAL; 


7=onusoe TPE CSCLARATIONS*/ 


Gaon. TVITve; . 
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Go W1il2> @1;3 
CAGL AMBIT (S1TPRE.ZZ); 
Moo =- lie 13 
Pee Oe] (1) sFLAGS7 = GLE TEEN 


Peeks sNt THE SUFFER COUNT AND ORTAIN THE DATA. CONVERT 
TRIM ASCII TD) WUMERICAL REPQESENTATION.#/ 


Tz I ¢ 26 THEN 


DO; 
LO J = @ TO 14; 
a FFER(J) = INI(SENSBUF(I) .INFO(J) - 28H); 
END; 
ENDS 
BGSbsho3 
I = 33 


LD) J = @ TO 14; 
BUFFER(J) = INT( SENSBOF(I).INFO(J) - 22H); 


/* THE NEXT STEP [S TO CONSOLIDATE THE INPUT INFORMATION 
iNTO IHE APPROPRIATE VARIABLES */ 


DO; 
Y$SENS = ((100a * BUT? 
(183 * BUFFS 
(13 * BUFFER ( 
(BOTTER(4))) 
YSSENS = ((1280 * R20F 


oe 


BEARING = ((1292 * BUF PSR 


(BUFFER (11) 
PANGS = ((133 * BUFFER 
(12 * BUFFER ( 
(BJFFER(14))) 
OND; 


fo 
i 


ALL THE SUBROUTINES WHICH ANALYZE THE DATA TO PRODUCE 
Z= TARGET’S PCSITION ON AN X-Y GRID*/ 

D3 
call writ2 (2(°Calliag »b2aaring_ analizer.% as 


call write (3(‘Calline taresst posit. )); 
END; 


/* LOAIL THE MEMORY SHARED #dITH TSE CORRELATION PROCESS*/ 


CALL AWAIT(@IDEOF,«#); 
i= ae 1G 


Ae 
u% 


SENSSNUM1 = SOSPER(2)5 


eal 





[YY3l = SeNS2I?(I-1).IY“E; 
Aoiat = SOS ITA); 
MSTGt = POSIT t1); 
ENT; 
/* 3ST THE ADVANCE [CQ SISNAL TSE END OF THIS PROCESSOR 2IN 
MoelHs SCEELULER*/ 


CALL ADVANCE(GIDPOS); 
END eOsPOS [Ts 


a ee A ee ee 
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(ee 


Vr 


5 
CORRE 
Pees 


Some Ge rons £9; /* 2ESINNINS 92 MOTTES. #/ 


Moe @E DSTEPMINES WHETEBER ANY INCOMING TAPGETS CAN 
LATE Mir TR OANY TRACKS ALREADY SEIN? TRACKSD IN TSE 


tn) 
Po 


er 


pee cero ele TEERE [5 A CORRELATION, THEN THE M@BIT iM 


ees TES TARGETS < POSITION, Y POSITION, AND TIME. 
me teees [5 NO COREELATION,TAEN TRE YCDULE ASSIGNS RECO) 
NEW TAPGET A NEY TRACK NUMBER AND ENTERS IT°S TRACE 
ae Mm Sols ITIN, Y SOSTITION, AND TIVE IN Pes TRACES 
tLe. #/ | 


om «0 od 


/* EXTURNAL DECLARATIONS */ 


UECLARE eee eee EU CTURE (TRACES NR WORD ,XSPOSIT INTEG 


Meeoolrl INTSGER,ITYME VWORD,CSé INTESEP ,S?D INTEGER, 
AS:UPOS INTESER,YS$FOPOS INTEGER) EYTERNAL} 


Pee LAR ACTIVESBUFF STRUCIURZ(IRACKSNR WORD, XSPOSIT INTEGER, 


YSPOSIT INTEGER,ITYME WORD) EXTERNAL; 


DECLARZ SENSSNUML INTEGER EXTERNAL; 
CECLARE (XSTGT,YSTGT)INTEGER EXTERNAL; 
CecLaRs TYMEL WORD EXTEQNAL; 


/* INTERNAL DECLARATIONS */ 


DECLARS (N,J,YFOIND) #ORZ; 
DECLAPE Z WORD; 

PeCLARE ¥ WORD INITTAL(2); 
LECLARE M SORD INITIAL(Z)3 


DECLAPE (TPUE,FALSE)WORD INITIAL (9 
CECLARE IZPOS(6) BYTE DATA( “IDPOSY’ 

ARE ACSUS(G)EYTE DATA( “ACBUFS” 
DECLAPE IDBUF(S)BYTE DAaTa( “IDBUFS’ 
DECLARE TASAC(S)2YTE CATA( “PABACY’} 


Tech 


re 8] 


? JOH); 


Se ee ee ee On 


we yo we wo bx} 


ECLARE (SENSOR, XTAR,YTAR )INTEGER; 
SCLAPE TMs s#ORD; 


DECLASE MSG1(*)EYTE INITIAL( “ENTERING CORRELATIONZ~ 
CECLARE MSG2(*)BYTE INITIAL( “LEAVING CORRELATIONZ”) 


Pg 


ADVA 


u 


jee! 
EY 


m 


/* SXTERNAL PROCEDURES */ 
THE ALVANCE MODILE ADVANCES THE VALJE OF EVCSIDSPARM. ¥*/ 
NCE: PROCEDORE(EVCSIDSPARM) SXTERNAL; 
DECLARE EVCSIDSPARY POINTER; 
END ADVANCE; 


AWAIT “OLJLE #ILL BLOCK THE CALLING PROGRAM FROM 


TECUTION JNTIL EVCSIDSPARM=FVCSTALSPARM. #/ 


AWAIT: PRICEDORE(EVCSIDSPARM,SVCSVALSPAQM) EXTERNAL; 


DECLARE EVCSIDSPARM POINTER; 
CESLARE EVCSVALSPARM WORD; 
IND AWAIT; 


TEE XMATCE MOLDOLE DETERMINES WHETHER THE INCOMING TARGETS 


XPOS 


ev adl 


Rests 


PrULGIeGOPRELATES WITH ANY BUTCSE XK POSITIONS Or TRACXS 
ARE ALREADY IN THE TRACKSTATLE. ay 


Pmt 


H: PRICEITRE(TASLESPTR,XTAR,N)#ORBD SCTERNALS 
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CECLARE TAPLFSPTS SITES; 
Peo GARE CTAP ic MDEGER3_ 
DECLare 4 wl 02D: 


“NEOLO PT Ce; 
meee MAN Ca “OLIEESCOMPAR ES TEE Y SUTJSE FOSITTION OF TRE T2ac< 
eee Ne MATCH “OLULE SD TEE INCOMING TARSETS Y POSITION 
Meee taR“MINeS IF TEESRE i5 A CORRELATION. Sey) 
fen tC: pOICSDURE( FUTUPEY, TAR) WORD EXLERNAL; 

T20LaArz FJTIREY INTEGER; 

DecLaPE YTAE INTESER; 

feoe Y MATCH; 

Peet so =Le “OLULH FILLS THER TRACXKSTASLE 4ITY TEACK SOMSEF, 
feof oN, Y FOSITION, ANU TIME OF ALL NEW TRACGS. af 


PASLas PROCELORE(™,XTAR,LTAR,I )SXIERNAL; 
DECLARE M #ORD; 7 
mee LARE (XTAR,YTAR) INTEGER; 
SCLARE T WORD; 
at TASLE} 


iecuse “JDJLE JPLAIES THE ACTIVESBUFF WITH TRACK NUMBER, 
mee ooit lon, § POSITION, AND TIME Jr ALL OLD TRACKS. "7 


QJTF: PROCELURE(TN,XTAR,YPAR,T) EXTERNAL; 

DECLARE (IN,T)#ORD; 

DECLARES (XTAR,YTAR)INTECER; 

END SUFF; 
meeeaRite® MOLOLE [S USED ITD PRINT JUT “ESSAGES. */ 
WRITE: PPICEDURE( PTR) EXISRNAL; 


DECLARE PTR POINTER; 
ENT WRITE; 


[oe nA Nee das kM) */ 


[TO Z=1 T0 12@08¢; 


CALL WRITE(@MS31);3 
CALL AWAIT(QIDPOS,.Z); 


SENSOR=SENSSNUM1L3 
XTAP=XSTGT} 

YTAR= se HH 

IME=TYME 

CALL ADVANCE(GISEOT); 
OVLURAWALI(ATASAC, 2); 
YIOOND==ZALSE; 

J2Z; 

Mix 


POE rroces ANG YSQUND=ZALSE; 


S=KMATCH( QITRACKSTA3LE,XTAR,N)3 
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e) 
TPCUND=EMAICA(TAACTSTASLA(J) .YSPIPOS .TTA2; 
fF YFOQNS=TRUE TEEN 
io 

“CALL BUPF(TRACCS$TARL(J) .TBACESNR, (TAR, TTAR, TMS) 
BN; 
ELSE 
N=J+1} 
ENDs 

END; 

I? J=25 THEN 

BOE 

GhupuAe neta ctdR TTA, 14S); 
“M=M+1; 
END; 


CALL ADVANCE (2ACBUPF); 
W=W+13 
CALL #¥RITE( 2MS32);3 


BND; 


END CORRELATION; /* END OF MOLULE */ 
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MegeaRe® SET LITERALLY “¢12", 
OJTSTAPLESPTE POINTER, 

eee TiS LITERELLY. “258°; 
JacslareJPDAT (5) BYTES DATA (°JPDATZ”), 
Smeny (S$) EYTE DATHX (“OTRDYY’), 
seour (5) byte tata (“acsurs’ 
tabas (5) byte data (’ 
wor? initial (2), 
fevori iaitial (2), 
emery 3 label public, 
Seewori initial (1); 


af 


DECLARE BUFF (4) STROUCTIJ2E (TRACTSNR WORD, XSPOSIT INTEGER, 
beeJoil INTEGER, TIME INTEGER, CSE INTEGER, 
SPC INTESER, FLAG BYTE); 


DECLASE OUTPUTSTABLE STRUCTURE (TRACKSNER WORD, XSPOSIT 
DN EGend, YSPOSIT INTESER, TIME INTEGER, 

ooh INTEGER, SPD INTSSER, FLAG SITE) 

EXTERNAL; 


@mitk: PROCELIRE (PTR) EXTERNAL; 
DECLARE PTR POINTER; 
eNT; 


ADVANCES: PROCEDURE (EVCSIDSPARM) EXTERNAL; 
CECLARE EVCSIDSPARM POINTER; 
END ALVANCE; 


AVAIT: PROCEDURE (EVCSIDSPARM, SYCSVALSPARY) SXTERNAL; 
DECLARE sVCSILTSPARM POINIER, 
SVCSVALSPAPRM WORD; 


ENS 


Sgr y. 3 $ 
eeoeee isc (8(°SEGIN TEST OF DISPLALY.% “)); 


Peet iliAGizs */ 


BUFF(1).IRACKSNR = 13 
BOFT(1).XSPOSIT = 5313 
BUFF(L).YSPOSIT = 1254; 
BUSF(1).TIWE = 1343 
BUSF(i).CSE = 249; 
RJFTF(1).SPL = 245; 
BUer(1).FLAG 2 SET; 


BUSF(Z).TRACESNR = 13; 
BUFF(S).X$POSIT = 212; 
BUFF(3).7SPOSIT = 2413; 
BOFZ(3).TIME = 246; 
SUFF(3).CSE = 138; 
3UFF(3).5?D = 120@; 
eee (e) fl AGe= SETS 
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END TEST; 


Pomedil> é13 

Saieawait (Gacdsuf, w); 

4 =m +i; 

Sail writ2 (2( “Extracting lata fron a duffar 
advance (3tanac); 


CALL AWAIT (390TRQDY, 1); 


CUTPUTSIABLE.TRACYSNR = 3UFF(J).IRACKSNR; 
eeu TslASLn.%SPOSIT = 39Fr(J).XSPOSIT; 
Gee IsTASLE.(SPOSIT = BUFF(J).YSPOSIT; 
Oem OTSTAPLE.IIME = BUSF(J) .TIME; 
OPeTTSTALLS.CSE = BIFF(S).CSE; 
OUTPUTSTABLE.S2D = BUPF(J).SPD; 
DUTPUTSTAELE.FLAG = SOFF(J) .FLAG; 


ae + (15 


Sqareiow! tac oar co LATE.S ))}call 


CALL #PITE(@( “BUFFER FILLED. ADVANCING DISPLAY.2”)); 


CALL ADVANCE (20PDAT); 
SND; 


— ow ee wee ere ee = eee ny 
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LOVANCZ: PEOCESURE (EYCSID 
FESLARQE TVCSILSPAEM POINTE 
=ND; 


eres) Sk TERNAL; 
a7 


BAIT: P2OCECCFE (SVCSISSPAQM, EVCSVALSPAR“) EXTERNAL; 
Seorre = =VCSICSPaARM POIWIER, 

BeCSeVALSPASM #9R5; 

iNT 


PIER: 2PO0CEDCRE (PTR) EXTERNAL; 
VECLARE PTR POINTER; 
ENT; 


CONVEPTSPASLE: PSCCEDURE (TABLESPTR) POINTER EXTERNAL; 
MecotAd? IREBLESPTR POINTER; 
END; 


DECLARE I WORD INITIAL (1), 

PIR POINTER, 

OUTSTABLE$PT2 OOINTER, 

SST LITHRALLY “2187, 

Q2Sel LITERALLY °208° 

DELIMITER LITERALLY °258°3 
JaclarajPLlrar (2) EYTE LArTa (°JPDATZ’), 
Sma (=° SYTS DATA (’OT2D72"), 

oe) BhT Ty 


Pees JOT ROTSTASLE STRICIGRE (TRACZSNRIWOALT, XSPOSIT INTESE 
ieee: IWIHGER, TIME PNTSSER, CSE INTEGE2, 
SPL INTEGER, FLAG BYTE) EXTERNAL} 


Deira s LocoeUs? STSUCTUPE (TRACKSNR WORD, XSPOSIT INTEGER, 
Mares it INOELER, TIVE INIESER, CSE INTE SER, 
SPD INTEGER, FLAS BYTE); 


DECLARE (OUTSTABLE BASED OUTSTABLESPTR) (26) STEUCTURE (T2ZSNR 
Crovestls, kS2 (12) SY DE 

Moe urd) SYTh, T (13) BYTE, CSE (12). SHTE. SPO 

Ee eeeT=, F2LIM BYTE); 


SOREL WEITS (2( “SNTBRING DISPLAY.Z%’)); 


TO wail. 013 

CeLL AwALT (SC 2DA@. 1)? 

Comma tite(s( ONT oRme DISPLAY LOOP.%’)); 
{a2t + 13 ~ 
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Daccemme eek ACiCoNe = OUTPUTSTABLE .TRACISNS; 
Peer ..ceOsll = QULPUISTASLE.XSPOSIT 
Peeccuebeter Cait = QUPPUTSIABLE .YPOS TT; 
Meee o> TIME = OUTPOTSIABLE .TIME; 
Beeeeors Cot = OUTPJISTABLE.CSE; 

Peer Orta PD = OUTPUTSTESLE.529; 

DOUsrors SURG = OUDPUISTASLE. FLAG; 


s* SONVERT DATA TO ASCII FOR QITPIT. */ 


outStadl2srptr = convertStabls (3locs aul?) 3 


Power DATA ON CONSOLE. */ 


CALL WRITE (Q( ‘TRACE NR X_POSI? Y_POSIT TIME COURSE 
io § = 3 to 253 
me suest2ble(J) .3 
taen call writes ( 
ani; 


en —ea2liniter 
outstabls(j)); 


i } 
- 
Q 


CALL ALVANCE (20TRLY); 


wal Fe 


Gin? 
Eis DISPLAY; 
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EXAMPLE #5 OUTPUT 


Entering IDPOSIT LOOP. 
ENTERING awe A 1 oT 
ENTERING CORRELATION 
ENTERING AWAIT 
BEGIN TEST OF DISPLAY. 
ENTERING AWAIT T 
ENTERING DISPLAY. 
ENTERING AWAIT 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
CALL ADVANCE(ID$POSIT). 
ENTERING ADVANCE 


Calling bearing analizer. 
Calling target _posit. 


ENTERING AWAIT 


ENTERING ADVANCE 
Entering IDPOSIT LOOP. 


ENTERING AWAIT 


ENTERING ADVANCE 


ENTERING AWAIT 


ENTERING ADVANCE 


LEAVING CORRELATION 
ENTERING CORRELATION 


ENTERING AWA IT 
Extracting data from a buffer shared with CORRELA 


ENTERING ADVANCE 


ENTERING AWAIT 
BUFFER FILLED. ADVANCING DISPLAY. 


ENTERING ADVANCE 
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ENTERING AWAIT 


ENTERING DISPLAY LOOP. 


TRACK NR X_ POSIT Y_POSIT TIME COURSE 
00 234c8 678.9 0067 240 
01 443.01 444.4 0175 240 


ENTERING ADVANCE 


ENTERING AWAIT 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
CALL ADVANCE(IDSPOSIT). 
ENTERING ADVANCE 


Calling bearing analizer. 
Calling target posit. 


ENTERING AWATIT 


ENTERING ADVANCE 
Entering IDPOSIT LOOP. 


ENTERING AWATT 


ENTERING ADVANCE 


ENTERING AWAIT 


ENTERING ADVANCE 


LEAVING CORRELATION 
ENTERING CORRELATION 


ENTERING AWAIT 
Extracting data from a buffer shared with CORRELA 


ENTERING ADV ANCE 


ENTERING AWATIT 
BUFFER FILLED. ADVANCING DISPLAY. 


ENTERING ADVANCE 


ENTERING AWATT 


ENTERING DISPLAY LOOP. 


TRACK_NR X_POSIT Y_POSIT TIME COURSE 
00 231.8 678.9 0067 240 
01 443.1 444.4 0107 240 


ENTERING ADVANCE 


216A 


SPEED 
0345 
0345 


10) oe 


SPEED 
0345 
0345 





ENTERING a Wagkec! T 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
EnterinCALL ADVANCE(ID$POSIT). 
ENTERING ADVANCE 


Calling bearing analizer. 
Calling target posit. 


ENTERING AWAIT 


ENTERING ADVANCE 
Entering IDPOSIT LOOP. 


ENTERING AWAIT 


ENTERING ADVANCE 


ENTERING AWATIT 


ENTERING ADVANCE 


LEAVING CORRELATION 
ENTERING CORRELATION 


ENTERING AWATIT 


Extracting data from a buffer shared with CORRELA 


ENTERING ADVANCE 


ENTERING AWAIT 
BUFFER FILLED. ADVANCING DISPLAY. 


ENTERING ADVANCE 


ENTERING AWA TIT 


ENTERING DISPLAY LOOP. 


TRACK_NR X_POSIT Y POs IT TIME COURSE 
00 codes O(S5.9 0067 240 
01 443.1 444.4 0107 240 
02 443.1 444.4 0006 240 


ENTERING ADVANCE 


ENTERING AWATIT 


Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
CALL ADVANCE(ID$POSIT). 
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SPEED 
0345 
0345 
0345 
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ENTERING ADVANCE 


Calling bearing analizer. 
Calling target _posit. 


ENTERING AWA TIT 


ENTERING ADVANCE 
Entering IDPOSIT LOOP. 


ENTER ING AWA IT 


ENTERING ADVANCE 


ENTERING AWA TIT 


ENTERING ADVANCE 


LEAVING CORRELATION 
ENTERING CORRELATION 


ENTERING AWA TIT 
Extracting data from a buffer shared with CORRELA 


ENTERING ADVANCE 


ENTERING AWATI T 
BUFFER FILLED. ADVANCING DISPLAY. 


ENTERING ADVANCE 


ENTERING AWATI T 


ENTERING DISPLAY LOOP. 


TRACK_NR X_POSIT Y_ POSIT TIME COURSE 
00 231.8 678.9 0067 240 
01 443.1 444.4 0107 240 
02 443.1 444.4 0006 240 
03 333.9 335.2 0175 240 


ENTERING ADVANCE 


ENTERING AWA TIT 


Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
CALL ADVANCE(ID$POSIT). 


ENTERING ADVANCE 


Calling bearing analizer. 


PASS) 


(Ey. 


SPEED 
0345 
0345 
0345 
0345 





Calling target posit. 


ENTERING AWA TI T 


ENTERING ADVANCE 
Entering IDPOSIT LOOP. 


ENTERING AWA IT 
ENTERING ADVANCE 
ENTERING AWAIT 


ENTERING ADVANCE 


LEAVING CORRELATION 
ENTERING CORRELATION 


ENTERING AWAIT 
Extracting data from a buffer shared with CORRELA 


ENTERING ADVANCE 


ENTERING AWAIT 
BUFFER FILLED. ADVANCING DISPLAY. 


ENTERING ADVANCE 


ENTERING AWAIT 


ENTERING DISPLAY LOOP. 


TRACK_NR X POSIT Y_POSIT TIME COURSE 
00 231.8 678.9 0067 240 
01 443.1 444.4 0107 240 
02 443.1 444.4 0006 240 
03 333.9 335.2 0175 240 
04 443.1 444.4 0242 240 


ENTERING ADVANCE 


ENTERING AoW A LT 


Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
Entering IDLE PROCESS. 
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TE. 


SPEED 
0345 
0345 
0345 
0345 
0345 





EXAMPLE #6 


This is the last and more powerfull example. Last 
because no time is left for more testing of the operating 
system. Powerfull because PROCO1] is loaded to one physical 
processor and PROCO2 is another physical processor. These 
two interactive processes use the synchronization and 
communication mechanism and also the hardware interrupt 
structure as it was configured to provide inter-real 
processor communication (to support the preemptive scheduling). 
Furthermore in this example only the ITC level is used to 
demonstrate the verifiable “loop free" structure of the 
operating system (the TC level is not linked with the 
operating ystem in this specific example). 

These two processes are initialized as ITC processes, in 
the same way as they initialized the MMGT and IDLE process. 
For their interactions, the inter-virtual processor 
synchronization mechanism is used. 

The address space descriptor (the base of the stack) for 
the IDLE process is 5000, for the MMGT process is 5500, for 
the first process is 6000 and finally for the second process 
is 7000. Four VP's are used per real processor. 

The input source code for these two processes is under 


the header EXAMPLE #6 INPUT. 
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Figure 57 illustrates some more output messages incorporated 


in new modules used for this current demonstration of the 
operating system (which were not included in Figure 55). 

The output to the printer is included under the header 
EXAMPLE #6 OUTPUT #1 for the first mocrocomputer and 
EXAMPLE #6 OUTPUT#2 for the second one. 

It can be seen from OUTPUT #2 that when the PROC#2 is 
waiting the occurrence of the event FLDES (to reach a 
specified value) because no other process is located on the 
physical processor, it starts executing the IDLE process 
(it outputs repeatedly the message ENTERING UPDATECOUNTER). 
When this specific event reaches the necessary value PROC#l 
Signals to PROC#2 (using the ADVANCE operation) the 
occurrence of this event. Since PROC#2 is loaded on another 
physical processor, the hardware interrupt structure is used 
to awaken this process (in OUTPUT #1 after the message 
ITCSADVANCE there is the message ENTERING HARDWARESINT). 
After receiving this signal, the physical processor exits 
the IDLE process and continues on the previous task (PROC#2) 
and so on. 

To ensure in this example that the hardware interrupt 
mechanism will be invoked, a different delay is used in these 


two processes. 
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LEVEL 


SEGURE 5/7. 


MODULE 
LTECSENIT 
KERNELSINIT 
ITCSAWAIT 
ITCSLOCATESEVC 
ITCSADVANCE 
GETSCOUNTER 
UPDATESCOUNTER 


HARDWARES INT 


MORE OUTPUT MESSAGES 
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OUTPUT MESSAGE 
ENTERING ITCSINIT 
ENTERING KERNELSINIT 
ENTERING ITCSAWAIT 
ENTERING ITCSLOCATESEVC 
ENTERING ITCSADVANCE 
ENTERING GETCOUNTER 
ENTERING UPDATECOUNTER 


ENTERING HARDWARESINT 





EXAMPLE #6 INPUT 


7: rue DROCZ1L.SRC te 0 a, 


Peouers < YO2E; 
SU22 BYTE Dara(33); 
LOES SYTE vATA(44)5 


ea) SYTR INITIAL ( PROC#1. INITIAL ENIRY INTC CLUTTER SUPPRESSION’), 
Desi INITIAL ( PROCHI. WAIT FOR DATA READY ey. 

MS33(*) BY™S INITIAL (°PROCEL. PERFOPMING CLUITER SUPPRESSION: FEAME #& “), 
*) BYTE INITIAL (°PROCH#1L. ADVANCE FILTER DESISN EVENTCOUNT 6 


ITCSAWAIT1: 2PEOCESDURE(EVCSID,AWAITEDSVALUE) EXTERNAL; 
PicLese ONCSIE ATE. 
AWAITEDSVALUS WORD; 


ITCSAIVANCE: PROCEDIRE(2VCSID) EXTERNAL; 
DECLAPE sVCSID SYTE; 
ENU} 


OUISCEAR: PROCELURE(CHAR)s; 
DECLAPE CREAR BYTS; 
cO WEILE (INPOT(2@DAK) AND 31H) = @3 END; 
OUTPUT (GOSH) = CHAR; 

ZND3 


JUISHEX: PROCELDYRE(2);3 
[TECLARE 2 BYTE; 
DECLAPS ASCII(*) BYTE DATA (°31234355799ARCDEF’ ); 
SALL OUTSCHAF(ASCII(SHR(B,4) AND @FH)); 
CALL JOTSCHAR(ASCII(3S AND OFR)); 


IT = @3 


POmzs 0 Loess; 

CALL OUTSCRAR(“S31(2Z))3 
END; 
SAGEM OUTSICHAR (CR) 3 
SACEPOUrSCHAR( LYS); 


Dome e Gl <= (Ore ) ; 
bows 104s: 
Chee Os Tsemmn« MSSe(Z)); 
END} 
CALL JJTSCHAP(CR); 
CALL DUTSCRAP(L?F); 
SkLL LTCSAMEITI(CSTPP,1): 


Ce lek. ft: /* << kee = x / 
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Boe ee LON 

Sins OUTS CHAS (MS Getz) ) > 
aND; 

GAUL Joreeeat L) 5 

SALL JITS$CHAR (C2); 

PG oeOurscune (LF); 


CABG JUTSCHAP(C2); 
CALL JUTSCHAR( LF); 


SEG TLGsADVANCS(ELOGS ); 


il; Ye «hile */ 


pio DUaE = / 





/* TILE PROCZZ.SRC L& 
pees S“MODULE: 20; 
DECLARE [ 2ynT: 
TESUARE Somer ALLY “2rH*, 
Pee mio enALLY dah’; 
SEoenes 2 SYTS 
menos (CS UPR ayes ATA(S3);3 
Pagar c here Oo hT A (44); 
Bo LAR = 
perc) BYTE INITIAL (°P29C#e2. 
MS52(7) BYTE INITIAL (°PROC#2. WAIT FOR 
Wea 5(*) BYTS INITIAL ( °PedC#2. 
M5G4(*) BYTE INITIAL « °“PROC#H2. 


[TCSAWAITLI: PROCEDIRE(SVCSID,AWAITEDSVALUE) EXTERNAL; 


vECLARE 


SND; 


BVG slo BYTE, 


AWATTEDSVALUJUE w# RT; 


ITCSATVANCE: PROCEDURE(EVCSID) EXTERNAL; 
TECLARE £VCSIT BYTE; 


aND; 


JUISCHAE: PROCEDURE(CHAR); 


DiEcLAre 


CHAR BYTE; 


DO WHILE (INPUT(@DA) AND 213) = 


TAS EN 
ENC; 


Cis nn,- P 


SDSH) = CHAR; 


ROCEDURS(3); 


VECLAFE 2 


PYTE; 


[TECLARE aASCII(* 
SAE be SUAS CTAR( A 
CALL JUTSCHAR(A 


ENC; 


a 
+ 


a5 
Jo Z = @ TO 465; 


S 
S 


DATA ( “212Z245578SA3CDEF”); 


HR(B,4) AND 
AND OFH)); 


CALL OUTSCHAR(MSS1(Z)); 


SND; 
CALL JUTSCHAR(C 
CALL JUTSCHAR(L 


T0 Z = 2 TO 45; 


R); 
F); 


CALL OUTSCEAR(MSS2(Z));3 


ENo; 
CALL JITSCHAR(C 
CALL DUTSCHAR(L 


R)3 
BP) 


CAUbehGsmw ATT 1 (DES , 2); 


ls >[lo* 1; 
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INITIAL ENTRY INTO FILTSR DESIGN 


CATA READY 


oy END; 


OPH) )5 


7 
fo 


PERFORMING FILIGR DESIGN ON FRAME # “), 
ADVANCE CLUTTER SUPPRESSION EVENTCOUNT’);3 


) 
) 


’ 
g 





2 ee ee Ow tos 
OAGe outs Chas (MS>S(7) ); 
SNe 
OSU oi oe 6 (1.35 
SELUL OURS CEs 2 Cog) $ 
SAGGwOOLSOHAR Gay 
COee= 2 ao; 
a2 CUe Ti Mess );} 
SND; 


coe = 2 $9 45 
OA 
2195 
C Adeis DUTSCEAP(CRy; 
SP LL eed SCRAP Cie) 
CALL ITCSADVANCE(CSUPP); 
ZNC3 /*® WEILE */ 


aes /*MODCLS */ 


Ze) 








EXAMPLE #6 OUTPUT i414 


ENTERING ITCSINIT 
ENTERING KERNELSINIT 
ENTERING GETWORK 
SET VP TO RUNNING: VP 
SELECTED S$DBR 
ENTERING UNLOCKVPM 
ENTERING CHECKPREEMPT 
ENTERING ITCSRETS$VP 
RUNNINGSVP$ID = 00 


It ott 
=) 
>) 


0550 


ENTERING I TC S$ AWAIT 


ENTERING ITCSRETSVP 
RUNNINGSVPS$ID = 00 
ENTERING ITCS$SLOCATESEVC 
ENTERING GETWORK 
SET VP TO RUNNING: VP 
SELECTED$DBR 
ENTERING UNLOCKVYFM 
ENTERING CHECKPREEMPT 
ENTERING ITCSRETSVP 
RUNNINGS$SVPS$ID = 01 
PROC#1. INITIAL ENTRY INTO CLUTTER SUPPRESSION 
PROC#1. WAIT FOR DATA READY 


0600 


ENTERING I TC $ AWATIT 


ENTERING ITCSRETS$VP 


RUNNINGS$VPS$ID = 01 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK 
SET VP TO RUNNING: VP = O01 
SELECTEDSDBR = 0600 


PROC#1. PERFORMING CLUTTER SUPPRESSION: FRAME # 01 
PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING I TCS ADVANCE 
ENTERING ITCSRETS$VP 


RUNN INGSVPS$ID 
ENTERING ITCS$LOCATES$EVC 


01 


ENTERING HARDWARES INT 
ENTERING GETWORK 

SET VP TO RUNNING: VP 

SELECTEDSDBR 

PROC#1. WAIT FOR DATA READY 


01 
0600 


ENTERING I TC S$ AWAIT 


ENTERING ITCSRETS$VP 


RUNNINGS$VPS$ID = 01 
ENTERING ITCSLOCATES$EVC 
ENTERING GETWORK 
SET VP TO RUNNING: VP = 0Q1 
SELECTEDSDBR = 0600 


PROC#1. PERFORMING CLUTTER SUPPRESSION: FRAME # 02 
PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


ENTERING I TCS ADV AN CE 


Bil 





ENTERING ITCSRETSVP 


RUNNINGS$VP$ID 
ENTERING ITCSLOCATESEVC 


O1 


iT) 


ENTERING HARDWARES INT 
ENTERING GETWORK 

SET VP TO RUNNING: VP 

SELECTEDSDBR 

PROC#1. WAIT FOR DATA READY 


01 
0600 


ENTERING I TC S$ AWATIT 


ENTERING ITC$RETS$VP 

RUNNINGSVPSID 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK 

SET VP TO RUNNING: VP 01 
SELECTEDS$DBR 0600 

PROC#1. PERFORMING CLUTTER SUPPRESSION: FRAME #_03 
PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


01 


MW 


ENTERING ITCSADVANCE 


ENTERING ITC$RETSVP 
RUNNING$VP$ID 
ENTERING ITCS$LOCATESEVC 


01 


ENTERING HARDWARES INT 
ENTERING GETWORK 

SET VP TO RUNNING: VP 

SELECTEDSDBR 

PROC#1. WAIT FOR DATA READY 


01 
0600 


ENTERING I TC $ AWATIT 


ENTERING ITCSRET$VP 

RUNNINGSVPSID 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK 

SET VP TO RUNNING: VP 01 
SELECTEDS$DBR 0600 : 

PROC#1. PERFORMING CLUTTER SUPPRESSION: FRAME # 04 
PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


01 


ENTERING I TCS ADVANCE 


ENTERING ITCSRETSVP 
RUNNINGS$VPSID 
ENTERING ITCS$LOCATESEVC 


01 


ENTERING HARDWARES INT 
ENTERING GETWORK 

SET VP TO RUNNING: VP 

SELECTED$DBR 

PROC#1. WAIT FOR DATA READY 


01 
0600 


ENTERING I TC S$ AWATIT 


ENTERING ITCSRETSVP 

RUNNINGSVPS$ID 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK 

SET VP TO RUNNING: VP 01 
SELECTEDSDBR 0600 

PROC#1. PERFORMING CLUTTER SUPPRESSION: FRAME # 05 
PROC#1. ADVANCE FILTER DESIGN EVENTCOUNT 


01 
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EXAMPLE #6 OUTPUT #2 


ENTERING ITCSINIT 
ENTERING KERNELSINIT 
ENTERING GETWORK 
SET VP TO RUNNING: VP 
SELECTEDSDBR 
ENTERING UNLOCKVPM 
ENTERING CHECKPREEMPT 
ENTERING ITCSRETSVP 
RUNNINGSVPSID = O04 


0550 


ENTERING I gieC SwaowW AIT 


ENTERING ITCSRETSVP 
RUNNINGSVPSID = 04 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK ; 
SET VP TO RUNNING: VP 
SELECTEDSDBR 
ENTERING UNLOCKVPM 
ENTERING CHECKPREEMPT 
ENTERING [TCSRETSVP 
RUNNINGSVPSID = 05 
PROC#2. INITIAL ENTRY INTO FILTER DESIGN 
PROC#2. WAIT FOR DATA READY 


0700 


ENTERING I TCS AWAIT 


ENTERING ITCSRETSVP 


RUNNINGSVPSID = 05 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK 
SET VP TO RUNNING: VP = 05 
SELECTEDSDBR = 0700 


PRCOC#2. PERFORMING FILTER DESIGN ON FRAME # 01 
PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING I TC SMADVANCE 


ENTERING ITCSRETSVP 


RUNNINGSVPSID = 05 
ENTERING I[TCS$SLOCATESEVC 
ENTERING GETWORK 
SET VP TO RUNNING: VP = 05 
SELECTEDSDBR = 0700 


PROC#2. WAIT FOR DATA READY 
ENTERING I TC S$ AWATIT 


ENTERING ITCSRETSVP 
RUNNINGSVPSID 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK 
SELECTEDSDBR 
ENTERING UNLOCKVPM 
ENTERING CHECKPREEMPT 
ENTERING ITCSRETSVP 
RUNNINGSVPSID 
ENTERING GETCOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 


ENTERING UPDATECOUNTER 


05 


0500 


07 
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ENTERING UPDATECOUNTER 

ENTERING UPDATECOUNTER 
ENTERING RDYTHISVP 
ENTERING ITCSRETSVP 

RUNNINGSVPSID 

SEQ VP TO REABY: VP 

ENTERING GETWORK 
SET VP TO RUNNING: VP 
SELECTEDSDBR 


PROC#2. 
PROC#2. 


ENTERING 


ENTER ING 


ENTERING 
ENTERING 


SET VP TO RUNNING: 


PROC#2. 


ENTERING 


ENTERING 


ENTER ING 
ENTERING 


ENTER ING 
ENTERING 
ENTERING 


ENTERING 
ENTER ING 
ENTERING 
ENTER ING 
ENTERING 
ENTERING 
ENTERING 
ENTERING 
ENTERING 


SET VP TO READY: 


ENTERING 


SET VP TO RUNNING: 


PROC#2. 
PROC #2. 


ENTERING 
ENTERING 


ENTER ING 
ENTERING 


SET VP TO RUNNING: 


PROC#2. 


ENTERING 


ENTERING 


I 2 Cra DV 


ITCSRETSVP 
RUNNINGSVPSID 

ITCSLOCATESEVC 

GETWORK 

vP 

SELECTEDSDBR 


ITCS AWA 


ITCSRETSVP 
RUNNINGSVPSID 
ITCSLOCATESEVC 
GETWORK 
SELECTEDSDBR 
UNLOCKVFM 
CHECKPREEMPT 
ITCSRETSVP 
RUNN INGSVPSID 


UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
LOCKVPM 
RDYTHISVP 
ITCSRETSVP 
RUNNINGSVPSID 
VP 
GETWORK 
VP 
SELECTEDSDBR 


it C SAwD V 


ITCSRETSVP 
RUNNINGSVPSID 

ITCSLOCATESEVC 

GETWORK 

WAzd 

SELECTEDSDER 


ENTERING LOCKVFM 


PERFORMING FILTER 
ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


A 


I 


PERFORMING FILTER 
ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


A 


07 
07 


05 
0700 
DESIGN ON FRAME # 02 


NCE 


us 


05 
0700 


WAIT FOR DATA READY 


‘5 


05 


0500 


07 


07 
07 


05 
0700 
DESIGN ON FRAME # 03 


BGE 


05 


05 
0700 


WAIT FOR DATA READY 


ITCS AWAIT 


ITCSRETSVP 
RUNNINGSVPSID 


05 


ENTERING ITCSLOCATESEVC 
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ENTERING 


ENTER ING 
ENTER ING 
ENTERING 


ENTERING 
ENTERING 
ENTER ING 
ENTERING 
ENTERING 
ENTERING 
ENTERING 
ENTERING 
ENTERING 
ENTERING 


GETWORK 
SELECTEDSDBR 
UNLOCKVPM 
CHECKPREEMPT 
ITCSRETS VP 
RUNN INGSVP$ID 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 


07 


UPDAENTER ING LOCKVPM 


RDYTHI SVP 
ITCSRETSVP 
RUNNINGSVPSID 


SET VP TO READY: VP 


ENTERING 


GETWORK 


SET VP TO RUNNING: VP 


SELECTEDSDBR 


PROC#2. PERFORMING FILTER 
PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING 
ENTERING 


ENTER ING 
ENTER ING 


I TGS. A D V 


ITCSRETS$VP 
RUNNINGSVPS$ID 

ITCSLOCATESEVC 

GETWORK 


SET VP TO RUNNING: VP 


SELECTEDSDBR 


A 


07 
07 


05 
0700 
DESIGN ON FRAME # 04 


NeGrE 


05 


05 
0700 


PROC#2%. WAIT FOR DATA READY 


ENTER ING 
ENTERING 


ENTERING 
ENTER ING 


ENTER ING 
ENTERING 
ENTERING 


4p 

ENTERING 
ENTERING 
ENTER ING 
ENTERING 
ENTER ING 
ENTER ING 
ENTER ING 
ENTERING 
ENTERING 
ENTER ING 
ENTERING 


ITCS AWA 


ITCSRETS$VP 
RUNN ING$VPS$ID 
ITCSLOCATES EVC 
GETWORK 
SELECTEDSDBR 
UNLOCKVPM 
CHECKPREEMPT 
ITCSRETSVP 
RUNNINGSVPSID 


UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
LOCK VPM 
RDYTHISVP 
ITCSRETSVP 
RUNNINGS VPSID 


SET VP TO READY: VP 


ENTERING 


SET VP TO RUNNING: 


PROC#2. 
PROC#2. 


GETWORK 


SELECTEDSDBR 


ENTERING ITCSADVANCE 


VP 


I 


Hou 


PERFORMING FILTER 
ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ne 


05 


0500 


07 


07 
07 


05 
0700 
DESIGN ON FRAME # 05 
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ENTERING ITCSRETSVP 
RUNNINGSVPSID 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK 
SET VP TO RUNNING: VP 
SELECTEDSDBR 
PROC#2. WAIT FOR DATA READY 


05 


05 
0700 


ENTERING [ TCS AWA TIT 


ENTERING ITCSRETSVP 


RUNNINGSVPSID = 05 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK 
SELECTEDSDBR = 0500 


ENTERING UNLOCKVPM 
ENTERING CHECKPREEMPT 
ENTERING ITCSRETSVP 
RUNNINGSVPS$ID 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTERENTERING LOCKVFM 
ENTERING RDYTHISVP 
ENTERING ITCSRETSVP 


07 


RUNNINGS$VPSID = 07 
SET VP TO READY: VP = 07 
ENTERING GETWORK 
SET VP TO RUNNING: VP = 05 
SELECTEDSDBR = 0700 


PROC#2. PERFORMING FILTER DESIGN ON FRAME # 06 
PROC#2. ADVANCE CLUTTER SUPPRESSION EVENTCOUNT 


ENTERING I TCS ADVANCE 


ENTERING ITCSRETSVP 


RUNNINGSVPSID = 05 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK 
SET VP TO RUNNING: VP 05 


SELECTEDSDBR = 0700 
PROC#2. WAIT FOR DATA READY 


ENTERING I TC $ AWATIT 


ENTERING ITCSRETSVP 
RUNNINGSVPSID = 05 
ENTERING ITCSLOCATESEVC 
ENTERING GETWORK 
SELECTEDSDBR 
ENTERING UNLOCKVFM 
ENTERING CHECKPREEMPT 
ENTERING ITCSRETSVP 
RUNNINGSVPSID 


0500 


07 


ENTERING UPDATECOUNTER 
ENTERING UPDATECOUNTER 


ENTERING UPDATECOUNTER 
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ENTERING 
ENTERING 
ENTERING 
ENTER ING 
ENTERING 
ENTERING 
ENTERING 
ENTERING 


UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUN TER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
UPDATECOUNTER 
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